webcomponents-cg

webcomponents-cg copied to clipboard

[!NOTE] Timebox: 1 month : November 17th

Background

Discussion in the last TPAC prep meeting pointed at the possible need for some deeper internal process to keep efficiently iterating on new web component features and specs and establish a somewhat more formal process. Having a more formal process can hopefully help the WCCG better plan for meetings with implementers, provide more focus, establish and organize feature champions and coordinate action items.

In the last few TPAC prep meetings there were always a wide range of specs and ideas that were floating around our spaces and repos. At the beginning of each TPAC prep session, there were a few meetings where the goal of the meeting was to "decide" which things we should mention in our TPAC reports and how to structure them. When breakouts were being scheduled, we had similar discussions about which specs we wanted to present. Given that each spec was in a different place, there isn't really a collective definition of what makes a certain spec "ready" to present to implementers in TPAC breakouts. So group members would say what they believed to be true about specs as best as they could remember, and in general the TPC meetings did happen and were successful and useful. However, it was brought up that a little more process definition to help us move specs and ideas through a defined workflow would let us always all know what status a certain spec was in without having to "remember". And that as a group we could collectively define what it means to be "ready" for a given stage in the process from idea -> implementation as best we can. That way its not just up to individuals, which means that "readiness" can vary wildly depending on who is championing what spec, but instead is known by all and has a more formal definition.

Objective

This issue is a proposal for how such an internal process might be established. The goal of this issue is to discuss and ultimately arrive at an adoptable process that the WCCG members are mostly agreed upon.

Process Proposal

Timebox base

Not all features or specs are the same size or difficulty. Some are harder/bigger than others. Therefore, we should adopt some baseline unit of time so that we can effectively timebox items going through the workflow described below. The timebox base should be the shortest unit of time a feature can be in particular workflow status. This base will allow for feedback loops in all the stages where needed and should also account for the busy lives of WCCG volunteers.

Since we all have busy lives, setting a short timebox seems unfair, but setting something too long stretches the timeline of a given feature. We should strive to pick a base long enough to get the work done but short enough as to not overly delay the overall feature.

Proposed time box base: 1 month Example: A feature in the RFC stage must stay in the RFC stage for at least 1 month (can be longer) before moving statuses.

[!NOTE] Larger features will need bigger timeboxes and thats ok. This just establishes the absolute minimum.

Workflow

If we think of some feature or spec as an item that exists in a workflow, that may help us get and stay organized to know where each spec we are working on exists in the flow so that we can efficiently delegate our time according to the highest value tasks for each workable item. Adopting a workflow may also enable tools to help us track (Trello, Github Projects) workable items and their statuses as well.

"Stop starting, start finishing"

The above is a phrase I learned from a lean agile training years ago, and I think it may apply here a lot of the time. The concept the phrase represents is that when there is a choice between creating something new and working to finish an existing item, priority should go to finishing the existing item. This wont always be applicable, sometimes new things will need to take precedence to existing items, and thats ok. In my opinion, the "stop starting, start finishing" mantra is a good baseline to adopt to help focus the work.

WIP limits

Lean agile practices would dictate that we would have some sort of WIP limits to keep work focused on finishing the in-progress items before starting new ones. However, the feedback from this group suggests that we feel like instituting WIP limits would be too limiting and might discourage participation.

Therefore, there shouldn't be any official WIP limits, but special care should be taken to avoid the following:

• Having a brand new proposal completely overshadow existing proposals in discussions, TPAC, etc.
• Having too many* proposals in progress at one time

• There wont be any set definition of what "too many proposals" looks like, but the process should center around keeping in mind that we can only present a certain number of proposals to implementers at TPAC, we can only have so many breakout sessions etc.

Additionally, proposal champions should impose WIP limits on themselves to make sure they aren't driving too many proposals individually for similar focus reasons.

Phases

The following are the phases/statuses that a workable spec/feature item can be in with a description of the task(s) and the conditions of changing states.

AN important part of this workflow probably needs to be that workable items cant skip phases. In order to give features the time and attention they deserve, we should focus on organization and not switch focus to new features even if they are really great ideas.

Likewise, feature contributors should pay close attention to the opportunity to break complex features into phases where each phase is a separately implementable feature and let the WCCG process organize and prioritize. The WCCG has found that it is a lot easier to get implementers on board with smaller, less complex features that iterate over time than larger, more complex features that have tons of edge cases.

1. Ideation

Description: Initial creation of feature shape. No formal commenting process, no presentation to WCCG required. Deliverable: WCCG GitHub issue tagged as "ideation" that outlines the new feature/idea Minimum timebox: none Definition of done: New WCCG GH issue tagged as "Proposal" with a streamlined, "complete", and representative example implementation. This "Proposal" issue is the issue that will be discussed in WCCG meetings in order to consider WCCG adoption.

2. Request for use cases

Description: Gather, synthesize, and prune a complete list of unique use cases for the purpose of presenting them to implementers. Use cases may get pruned further over time as proposals change shape, but gathering some upfront is valuable. Entrance criteria: GH Issue tagged as "Use Cases" Minimum timebox: 1 month Definition of done: list of uses cases added to the proposal GH issue

3. Conceptualization

Description: Further refinement of the initial idea, including pruning use cases, refining API shape/surface, implementer level of effort discussed, alternatives thrown out etc. Entrance Criteria: GH Issue tagged as "Concept" Minimum timebox: 1 month

4. Feedback

Description: a period for feedback after a proposal has settled into an API shape for the community to weigh in before proceeding. Community feedback may require more use cases and conceptualization, in which case the proposal would change back to those statuses Entrance criteria: A relatively stable* conceptual proposal. Minimum timebox: 1 month

• Its hard to define exactly what constitutes a "stable proposal", but generally speaking a proposal should be considered stable when there are not many changes being made and not many open questions left unanswered.

5. Implementer proposal

Description: Present the concept, or idea to implementers. A proposal might go through this state many times depending on how many times it gets presented. Ideally though, we'd want to present mostly shaped concepts. Entrance criteria: GH issue tagged as "Implementer proposal" Definition of done: The proposal/concept was presented in some capacity to a group of implementers

6. Consensus

Description: This state is achieved when the community and implementers come to a consensus that a proposal in its given shape satisfies a concrete issue with the platform and is worth implementers taking on. Entrance criteria: Implementers of the major browsers the WWCG interacts with giving a clear signal of agreement/consensus on the proposal. Links to GH issue comments, discussion threads added to the GH issue if possible for organization.

7. Implementation Support

Description: Once a feature gets presented to implementers, it can undergo extensive changes. Assuming implementers agree that the feature is needed, the problem statement needs a solution etc, their feedback will further shape the feature and ultimately the implementers will agree on what to implement and how. This status can also be a long running status, because the WCCG does not control how long it takes for implementers to implement a feature. Exiting this status will depend on a lot of factors. The feature champion is responsible for adding WPTs, addressing implementer open questions, testing implementation approaches in canary browser versions as they arrive, etc. Minimum timebox: none

Definition of done: Feature has been presented to implementers and agreement achieved. Feature implementation is stable in all browsers for which the WCCG has access to implementers.

8. Dropped

Definition: a status that recognizes that a particular proposal/idea was discussed, but did not move forward in the process towards being implemented in browsers. When a proposal is dropped, if a new proposal is moved forward instead, the link to the new proposal should be added to the closed/dropped proposal for linking and consistency.

9. Implemented

Definition: The cleanup stage to help define a feature as "done".

Definition of done: Feature is implemented and released in all browsers for which the WCCG has access to implementers.

Non-workflow process guidelines

In addition to the actual flow of workable items through a process, there are a few other guidelines that can help the WCCG get and stay organized.

Github

Only projects listed on the WCCG Github Projects board will be considered "in progress" by the WCCG.

The WCCG Github projects board (to be created) should serve as the source of truth for proposals that the WCCG is actively working on guiding the process towards implementation. That is not to say that the WCCG actively guides ALL things that browsers implement that concern web components. But the ones that the WCCG chooses to focus on should be documented in the Github Poject board accordingly and that project reference should serve as the organizational "hub" for all information about a particular proposal that exist in other repos.

Tagging

All proposals being actively worked by the WCCG should have both a Github Project card AND a GH issue associated. The Github project card should serve as the organizational hub for that proposal and contain links out to all of the relevant information about that proposal, including links to: the actual spec GH issue being discussed, use cases, issues in other repos, links to conversation threads on IRC, implementer feedback/acceptance, etc.

As such, all GH issues in the WCCG repo should have a tag indicating what status they are currently in. Proposal issues that are not currently being worked by the WCCG should automatically have a tag for "Ideation" by default. The "Ideation" tag will be the tag that separates workable/potentially workable proposal GH issues from other sorts of housekeeping issues that the WCCG creates.

Only issues, no discussions

For consistency, only WCCG GH issues shall be considered workable. Discussions are not workable.

Timeboxing

WCCG work should prioritize and require timeboxing for all feedback loops. Each feedback loop timebox should

• be discretely communicated in a highly visible place on the GH issue at all times
• should be commensurate with the complexity of the feature (more time for more complex features)

Actively avoid infinite feedback loops

The "ideation" and "conceptualization" phases may require several feedback loops depending on the complexity of the feature. In order to keep features moving and not endlessly swirl on feedback and iteration, a workable item may have a maximum of 3 feedback loops of at least 1 month each. The total feedback time should not exceed 9 months. If a feature somehow requires more than 9 months of total feedback, that item should be divided into smaller workable items re-architected, and re-introduced to the process.