forked from wet-boew/GCWeb
-
Notifications
You must be signed in to change notification settings - Fork 0
/
méli-mélo-en.html
268 lines (232 loc) · 20 KB
/
méli-mélo-en.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
---
title: Experimental features
description: Reusable features that are into a preliminary state of experimentation packaged in time-limited méli-mélo package.
lang: en
altLangPage: méli-mélo-fr.html
dateModified: 2024-05-23
css:
- href: https://use.fontawesome.com/releases/v5.8.1/css/all.css
integrity: sha384-50oBUHEmvpQ+1lW4y57PTFmhCaXp0ML5d60M1M7uH2+nqUivzIebhndOJK28anvf
---
<p>Experimental features are reusable features that are in a preliminary state of experimentation packaged in time-limited méli-mélo compilation package. Those features are built from custom CSS and/or JavaScript code. Once a feature is developed and minimum requirements are met, it is packaged in a méli-mélo compilation which can be deployed and ready for use within one to two weeks on Canada.ca. Check out <a href="#mli-mlo-list">existing experimental features</a> that are currently packaged in active méli-mélo compilations.</p>
<div class="alert alert-info">
<p><strong>Did you know?</strong> Support for experimental features is provided during weekly <a href="https://github.com/wet-boew/wet-boew/wiki/WET-Office-hours,-Heures-de-service-de-la-BOEW">WET Office hours</a> held remotely every Tuesday afternoon.</p>
</div>
<h2 id="mli-mlo-comp">Compilations</h2>
<p><strong>Every compilation's life expectancy is estimated to be approximately one (1) year</strong>, after which point it becomes "frozen" (deprecated). This should provide a feature's sponsor enough time to find resources to make their feature progress toward an official GCWeb feature. Using a <a href="compilation-gelé/index-en.html">frozen méli-mélo compilation</a> on any web page is strongly discouraged. It must be replaced by the corresponding GCWeb feature or another méli-mélo compilation, or simply removed.</p>
<p>Features are grouped into compilations in order to quickly:</p>
<ul>
<li>initiate usability research;</li>
<li>initiate preliminary discussion with key organizations;</li>
<li>transform the feature into a high-quality reusable product adapted for GCWeb;</li>
<li>regroup and ease central coordination for new innovations.</li>
</ul>
<h3 id="mli-mlo-list">Active méli-mélo compilations and their features</h3>
<p>Users of experimental features <strong>must</strong> ensure they are able to promptly apply any code adjustment of the pages leveraging a méli-mélo compilation. Users <strong>must expect and anticipate the risk</strong> of having a breaking change on their pages using experimental features. That risk can be mitigated by engaging with the experimental sponsor and by working with them to progress the feature toward its stabilization.</p>
<ul class="row list-unstyled wb-eqht-grd mrgn-tp-md">
{% for item in site.data[ "mli-mlo" ].packages %}
<li class="col-xs-12 col-md-4 mrgn-tp-md mrgn-bttm-md">
<div class="brdr-tp brdr-rght brdr-bttm brdr-lft hght-inhrt">
<h4 class="mrgn-tp-md mrgn-rght-md mrgn-bttm-md mrgn-lft-md">{{ item.nom }}</h4>
<div class="mrgn-rght-md mrgn-bttm-md mrgn-lft-md">
<ul class="mrgn-bttm-lg mrgn-lft-md">
{% for pack in item.libs %}
{% assign indexPage = site.data[ "mli-mlo" ].subProjects | where: "nom", pack | first %}
<li><a href="/gcweb-compiled-demos/méli-mélo-demos/{{ item.nom }}/{{ pack }}/{{ indexPage.mainpage }}">{{ pack }}</a></li>
{% endfor %}
</ul>
</div>
</div>
</li>
{% endfor %}
</ul>
<p><small><a href="compilation-gelé/index-en.html">View frozen and deprecated méli-mélo compilations</a>.</small></p>
<h2 id="checklist">Experimental feature checklist</h2>
<fieldset class="gc-chckbxrdio">
<legend id="requirements">Minimum requirements for <strong>introducing a new feature</strong> are:</legend>
<ul class="list-unstyled lst-spcd-2">
<li class="checkbox">
<input type="checkbox" id="req1">
<label for="req1">Must be reusable;</label>
</li>
<li class="checkbox">
<input type="checkbox" id="req2">
<label for="req2">Must not contain any interference with WET-BOEW & GCWeb, meaning no component implicit override nor conflict. When possible, component extension should be contributed in the <a href="../components/provisional-en.html">provisional</a> or stable component instead;</label>
</li>
<li class="checkbox">
<input type="checkbox" id="req3">
<label for="req3">Must conform to our accessibility standard (WCAG 2.1 Level AA) and be built with security in mind. Accessibility conformance and the security aspect remains the responsibility of the publisher when implementing the feature into a web page;</label>
</li>
<li class="checkbox">
<input type="checkbox" id="req4">
<label for="req4">Must be designed with conformance with the <a href="https://design.canada.ca/architecture/canada-content-information-architecture-specification.html">Canada.ca content and information architecture specification</a> in mind. The conformance to directives, standards and specifications remains the responsibility of the publisher when implementing the experimental feature into a web page;</label>
</li>
<li class="checkbox">
<input type="checkbox" id="req5">
<label for="req5">Must not impact any content by default on page load by leveraging closure techniques unless the feature is explicitly activated through the HTML, either by using a CSS class or data attribute, for example: <a href="https://wet-boew.github.io/wet-boew/demos/helloworld/helloworld-en.html">sample WET-BOEW plugin</a>;</label>
</li>
<li class="checkbox">
<input type="checkbox" id="req6">
<label for="req6">Must have its name in the right format (see <a href="#feature-name">feature name example below</a>).</label>
</li>
<li class="checkbox">
<input type="checkbox" id="req7">
<label for="req7">Must be <a href="#sponsor" rel="help">sponsored<sup aria-hidden="true"><span class="fas fa-info-circle"></span></sup></a> by a department with an active representative of that department;</label>
</li>
<li class="checkbox">
<input type="checkbox" id="req8">
<label for="req8">Must include an <a href="#implementation-plan" rel="help">implementation plan<sup aria-hidden="true"><span class="fas fa-info-circle"></span></sup></a>;</label>
</li>
<li class="checkbox">
<input type="checkbox" id="req9">
<label for="req9">Must have a demo/working example published for each individual sub-feature and style, meaning each JS configuration and CSS class respectively;</label>
</li>
<li class="checkbox">
<input type="checkbox" id="req10">
<label for="req10">Must be fully tested by a representative of the sponsored department, either via GitHub pages or locally. The testing confirmation must be documented via a comment in the GitHub pull request.</label>
</li>
<li class="checkbox">
<input type="checkbox" id="req11">
<label for="req11">Either inside the working example or via a comment in the GitHub pull request, the following must be written:</label>
<ul class="disc mrgn-lft-xl mrgn-bttm-lg">
<li>Clear and simple explanation of the new feature;</li>
<li>The impact on the sponsored department;</li>
<li>The impact on the public.</li>
</ul>
</li>
</ul>
</fieldset>
<fieldset class="gc-chckbxrdio">
<legend id="requirements">Minimum requirements for <strong>updating a feature</strong> are:</legend>
<ul class="list-unstyled lst-spcd-2">
<li class="checkbox">
<input type="checkbox" id="req-u1">
<label for="req-u1">Must remain reusable;</label>
</li>
<li class="checkbox">
<input type="checkbox" id="req-u2">
<label for="req-u2">Must not interfere with WET-BOEW & GCWeb, meaning no component implicit override nor conflict;</label>
</li>
<li class="checkbox">
<input type="checkbox" id="req-u3">
<label for="req-u3">The change/update must be done in conformance with our accessibility standard (WCAG 2.1 Level AA) and remain secure. Accessibility conformance and the security aspect remains the responsibility of the publisher when implementing the feature into a web page;</label>
</li>
<li class="checkbox">
<input type="checkbox" id="req-u4">
<label for="req-u4">The change/update must be designed with conformance with the <a href="https://design.canada.ca/architecture/canada-content-information-architecture-specification.html">Canada.ca content and information architecture specification</a> in mind. The conformance to directives, standards and specifications remains the responsibility of the publisher when implementing the experimental feature into a web page;</label>
</li>
<li class="checkbox">
<input type="checkbox" id="req-u5">
<label for="req-u5">Must not impact any content by default on page load except when explicitly activated;</label>
</li>
<li class="checkbox">
<input type="checkbox" id="req-u6">
<label for="req-u6">Must review the working example to ensure it remains accurate where:</label>
<ul class="disc mrgn-lft-xl mrgn-bttm-lg">
<li>Updated configuration remains fully demonstrated;</li>
<li>Added configuration is demonstrated;</li>
<li>Removed configuration is cleaned from existing examples.</li>
</ul>
</li>
<li class="checkbox">
<input type="checkbox" id="req-u7">
<label for="req-u7">Must review and report progress toward the feature stabilization as described in the implementation plan. Progress is reported by logging the history of the completed items and by reporting the state of items currently in progress;</label>
</li>
<li class="checkbox">
<input type="checkbox" id="req-u8">
<label for="req-u8">Must be fully re-tested by a representative of the sponsored department, either via GitHub pages or locally. The testing confirmation must be documented via a comment in the GitHub pull request.</label>
</li>
<li class="checkbox">
<input type="checkbox" id="req-u9">
<label for="req-u9">Must describe the change/update in the content accompanying the experimental feature working example or via a comment in the GitHub pull request. The description must include:</label>
<ul class="disc mrgn-lft-xl mrgn-bttm-lg">
<li>Clear and simple explanation of the change/update;</li>
<li>The impact on the sponsored department for that change/update;</li>
<li>The impact on the public for that change/update.</li>
</ul>
</li>
<li class="checkbox">
<input type="checkbox" id="req-u10">
<label for="req-u10">Should update the implementation plan to ensure it remains complete, accurate, and realistic toward the experimental feature stabilization;</label>
</li>
<li class="checkbox">
<input type="checkbox" id="req-u11">
<label for="req-u11">May provide instructions and/or a mechanism to the publisher on how to implement and transition toward the new markup caused by the update;</label>
</li>
</ul>
</fieldset>
<h2>Creating a new experimental feature</h2>
<p>Have a feature ready to be submitted and be packaged in one of our méli-mélo compilations? <a href="#checklist">Check out our requirements checklist</a>.</p>
<h3>Get started</h3>
<p>Below are instructions on how to create a new experimental feature in GCWeb.</p>
<div class="panel panel-info">
<div class="panel-heading">
<h4 class="panel-title">Tip to quickly get started!</h4>
</div>
<div class="panel-body">
<p>Start by coding and/or exposing your feature and its demo(s) by leveraging the <a href="https://github.com/wet-boew/gcweb-jekyll">GCWeb Jekyll theme</a> before your contribution to GCWeb.</p>
</div>
</div>
<ol class="lst-spcd-2">
<li>Consider that your feature's code is going to be all included in one (1) JavaScript file and/or one (1) CSS file. That merge is done alphabetically based on the location and the file name.</li>
<li>Create a new feature folder inside the <a href="https://github.com/wet-boew/GCWeb/tree/master/m%C3%A9li-m%C3%A9lo"><code>/méli-mélo</code></a> GCWeb root folder.</li>
<li id="feature-name">Name your feature and its folder using the following notation: <code>YYYY-MM-[FeatureName]</code>. The year and month must correspond to the feature's initial publication date. For example, "2021-05-steps".</li>
<li>Create and publish your demo/working example for each individual sub-feature and style, meaning each JS configuration and CSS class respectively, either by using the <a href="https://github.com/wet-boew/gcweb-jekyll">GCWeb Jekyll theme</a> or GCWeb itself.</li>
<li>Designate a <a href="#sponsor" rel="help">sponsor<sup aria-hidden="true"><span class="fas fa-info-circle"></span></sup></a> for the feature.</li>
<li>Build and publish an <a href="#implementation-plan" rel="help">implementation plan<sup aria-hidden="true"><span class="fas fa-info-circle"></span></sup></a>.</li>
<li>Ensure all <a href="#requirements">minimum requirements listed above</a> are met.</li>
<li><strong>Test your code</strong>, optionally by following the instructions on <a href="../docs/developing-en.html">developing for GCWeb</a> or via your GitHub pages by leveraging GCWeb Jekyll theme.</li>
<li>Submit your new feature through a GitHub Pull request (PR) in the <a href="https://github.com/wet-boew/GCWeb/">GCWeb repository</a>; please consult the <a href="https://github.com/wet-boew/GCWeb/blob/master/CONTRIBUTING.md">contribution guidelines</a>.</li>
<li>If changes are requested on your PR after the technical review (as per <a href="#tech-checklist">checklist below</a>), collaborate with the WET-BOEW team to address every concern until it gets approved. Concerns that are explicitly identified as optional or recommended can optionally be addressed later during a subsequent contribution. For reference, first-time contributions usually require 3+ rounds of back-and-forth code review taking a week each time.</li>
<li>Once your PR is approved, your feature will be assigned to a <a href="#mli-mlo-comp">méli-mélo compilation</a> and deployed on Canada.ca at the next release window (approximately one (~1) week after code is merged).</li>
<li><strong>Strongly recommended</strong>: after release, update the experimental feature code by executing the implementation plan and addressing all TODO's and concerns identified by the WET-BOEW team.</li>
<li><strong>Recommended</strong>: whenever possible, participate at the weekly <a href="https://github.com/wet-boew/wet-boew/wiki/WET-Office-hours,-Heures-de-service-de-la-BOEW">WET Office hours</a> on Tuesday afternoon. The WET-BOEW team will be able to help you progress in your contribution and execute your implementation plan by finding ways to remove any technical or procedural barriers you may encounter.</li>
</ol>
<p class="mrgn-tp-lg">See <a href="2021-05-steps/index.html">2021-05-steps</a> and its <a href="https://github.com/wet-boew/GCWeb/tree/master/m%C3%A9li-m%C3%A9lo/2021-05-steps">folder on GitHub</a> as a complete example of an experimental feature containing all the required information.</p>
<details id="tech-checklist" class="mrgn-tp-lg mrgn-bttm-lg">
<summary>Technical review checklist</summary>
<p>This list contains the technical steps that the WET-BOEW team uses to approve new experimental features.</p>
<ul>
<li>Ensure a <a href="#sponsor">project sponsor</a> with a valid point of contact is clearly identified;</li>
<li>The experimental feature's folder name follows the proper naming convention: <code>YYYY-MM-[FeatureName]</code>;</li>
<li>Ensure each JavaScript feature and each CSS style comes with a demo/working example;</li>
<li>Perform a code review to ensure there are no override nor conflict with GCWeb and/or WET-BOEW;</li>
<li>Perform a quick check for any major or obvious web accessibility and security issues;</li>
<li>Ensure the feature doesn't impact any content by default on page load unless the feature is explicitly activated through the HTML, either through the use of a CSS class or data attribute;</li>
<li>Review the <a href="#implementation-plan">implementation plan</a> to ensure it contains reasonable due dates and deliverables toward the feature stabilization.</li>
<li>Ensure the project sponsor does report on the progress of the implementation plan.</li>
<li>Ensure the change or the initial commit is described as required.</li>
<li>Ensure the experimental feature, change, and initial commit have been fully tested by a project sponsor representative verifiable via an explicit comment in the GitHub pull request.</li>
<li>Applicable during an update: review if the experimental feature is worth being included in additional active méli-mélo compilations based on expected progress toward feature stabilization, progress in fixing issues/TODO's, and formal feedback received or ongoing discussions.</li>
</ul>
</details>
<h4 id="sponsor">Sponsor</h4>
<p>A sponsor is an entity responsible for ensuring an experimental feature progresses toward a stable & widely reusable feature as per the implementation plan. The sponsor will most likely be the author of a feature, representing their department.</p>
<h4 id="implementation-plan">Implementation plan</h4>
<p>The implementation plan, also known as a planning horizon, is meant to set milestones in order to get an experimental feature stabilized into the WET-BOEW / GCWeb code base. It must contain the following milestones:</p>
<ul>
<li>Engagement with the Digital Transformation Office (DTO) at the Canadian Digital Services (CDS), ESDC;</li>
<li>Review and perform the identification of the feature transformation requirements to be able to complete the integration progress into GCWeb;</li>
<li>Produce accessibility conformance report and attach usability report (if any);</li>
<li>Transform the experimental feature into a GCWeb provisional feature when a broader user acceptance testing is required;</li>
<li>Complete feature stabilisation task, including, amongst other things, working example translation, writing guidance, publishing <abbr title="Accessibility Conformance Reports">ACR</abbr>s, feature API documentation, etc.</li>
</ul>
<p>Each item of the plan must have an <strong>estimated due date</strong> as an indicator to measure integration progress into GCWeb. The expectation is to get the experimental feature fully integrated into GCWeb within its lifespan of approximately one (1) year. See an <a href="https://raw.githubusercontent.com/wet-boew/GCWeb/master/m%C3%A9li-m%C3%A9lo/2021-05-steps/meta.md">example of an implementation plan</a>.</p>
<p>To maintain your experimental feature active within subsequent méli-mélo compilations or to extend the (1) year experimental feature lifespan, you must clearly show progress to the WET-BOEW team that: (1) there is clear evidence that work is underway to advance the experimental feature toward stabilization; and (2) there are no significant ongoing concerns regarding the experimental feature. It may be possible that a revised implementation plan is requested along with the completion of some commitments prior to packaging the experimental feature into a new active méli-mélo compilation.</p>
<h4>Versioning</h4>
<p>This framework for méli-mélo compilations and experimental features is excluded from the <a href="https://wet-boew.github.io/wet-boew-documentation/decision/14.html">GCWeb public versioning API</a>. Any change or removal would only trigger a patch release of GCWeb. This means developers of experimental features are fully responsible to document any subsequent change they make to their experimental feature and optionally to provide migration mechanisms when applicable.</p>
<h2 id="all-experiments">List of all experimental features</h2>
<p>Check out <a href="#mli-mlo-list">existing experimental features</a> that are currently packaged in active méli-mélo compilations.</p>
{% assign melimelo_pages = site.pages | where: "output", "false" | where: "feature", "méli-mélo" | sort: "componentName" | reverse %}
<ul>
{% for feature in melimelo_pages %}
{% assign mmBasePath = feature.path | slice: 0, 10 %}
{% if mmBasePath == "méli-mélo/" %}
<li><a href="{{ feature.componentName }}/détails-en.html">{{ feature.componentName }}</a></li>
{% endif %}
{% endfor %}
</ul>
<div class="well mrgn-tp-lg">
<h2 class="h4 mrgn-tp-sm">See also:</h2>
<p><a href="../thématique/gc-thématique-en.html">GC promotional thematics</a> for progressive enhancement custom code designed to support promotions with a fixed end date that affects a set of pages.</p>
</div>