mark-tate
commented
1 year ago This is great, we should turn it into a document.
The focus point for everyone should be the release plan. Everything should be on there and that helps us iterate across 3 deliverables (design, content, development) If you are working on something and it's not on a release plan, then there is no visibility to the rest of the team and no pressure to complete it. Things do not need to release together but with enough visibility of what we deliver and when, then everyone is aligned on scope and timelines.
I think we need a business case for everything we do and that business case, should speak to a known stakeholder(s) who are ready to use the component. Otherwise, we maybe building components but folks might not be using them. This is required before a kickoff.
We have a clear version roadmap per component, which considers the dependencies of other components/patterns. This is something we are sorely missing. The roadmap in it's present form, does not break things down into releases and so the perception it creates for the team, is that we deliver everything in one go, before we move on to the next component. There are things we can return to, when they are eventually needed. We can use scope to get an initial component out and build from there.
james-nash
joshwooding
Some process proposals to aid component asset delivery.
Publish and deliver to dates Would hard dates on site provide impetuous and increase sense of accountability? I’m not sure we would need to work to sprints but… Reinforce kick-off meetings with very clear outcomes The outcome of a kick-off would be: • Agreed scope • Agreed timescales • Allocated responsibilities Post kick-off dates (and owners?) would be published on site To facilitate that… Deliverables are split into separate issues We move to separate issues for: • Code • Figma • Site docs Ideally released at the same time, but not a blocker otherwise. To be transparent about that… Site docs added as a status column We track and make site documentation status visible to all. If it’s not complete we make that clear (can we use the new badge as per Foundations?). Initial release is minimum feature set We release the minimum viable component, for either our sponsors or our own purposes (site). If neither, we take an educated guess, based on tech effort. Feature set is agreed by all representatives on the kick off and determines the agreed timescales. We have a clear version roadmap per component, which considers the dependencies of other components/patterns. Versions are public (on GitHub?) and specs only address the current version. Patterns behaviours are recorded but out of scope (for now) We agree and document (publish?) our definition of components and patterns. We agree how this definition reflects our roadmap and implementation strategy. Pattern of use are not included in the MVP delivery. We record the pattern and document it when prioritised for delivery. Sponsor program is documented We have a single source of truth for sponsor contacts, discussions, feedback, and actions. Sponsor priorities are linked. Matrix is linked. Provides a resource for contributing to scope. Steering committee roles and responsibilities, + minutes and actions, are documented. SMEs are responsible for their individual issue Design delivers specs and figma component, and contributes to the usability docs. Dev delivers the code, and contributes to the technical documentation. Content delivers the site docs, providing the necessary usability guidance, alternatives, tone of voice, and QA. Each SME is responsible for getting issue to DONE. Accessibility is parity-only Something we’ve discussed, already. We guarantee parity with UITK from an accessibility perspective. We put a community contribution channel in place to crowd source improvements. This is published on site, and means we could… Not produce accessibility specs (for now) I’m not massively keen on this, but if we aim for parity we don’t need to validate the accessible experience. We could fast-follow (perhaps in Q1/2 next year) on ADA docs to enhance quality. This means… Design focus on characteristics spec The characteristics spec serves as the key medium for visual communication during build pairings. We use that spec to drive visual design, tokens, and theme updates. As a result… Interaction spec is lightweight The interaction spec describes any interaction behaviours benefit from additional explanation. I.e., behaviour may have different interpretations across systems/ it’s unique to our component/ we’re validating a UITK interaction. For example, but not limited to: • User navigation, selection, onward action • Autocompletion/ filtering/ incremental search • Responsive/ overflow behaviour • Progressive/ information reveal Progress reviewed by interim check-ins Recurring meeting is scheduled with leads and representative SMEs throughout delivery. Progress is reviewed and risks identified. Scope, Resource, or Duration is addressed as required.
Go/No go prior to code delivery A formal decision is made on delivery (1w/5d?) prior to agreed release of code. Acceptance criteria is defined for 'go' or 'no go'. If 'no go', we publish reason and expected date.