[ Ideation ][ Process ] WCCG Process proposal #99
Comments
|
Love this document - I'm always a fan of more process, and I really appreciate the details in here. It would be good to know where we want to codify this, potentially that is in the WCCG repo README, such that it is easily referenceable. RE Timebox Base: I think 1 month is fine, although logistically, what does that look like for the group - is that just a single WCCG meeting? I think we've often had success when there is one meeting to introduce the topic, and another to get final thoughts before pushing it forward, but I'm not sure if we'd want to adopt a timeframe in "X number of meetings" RE Workflow: we don't need to get into the finer grain details but I agree that tracking active tasks in Github Projects would be really valuable. Highlighting current priorities and where they are has always been something I think we've wanted to be better at, and I think a tool that's already integrated with where we want discussions / specs to be (Github) makes the most sense. RE WIP Limits: love it - I do think we run up against the fact that different developers are interested in different topics, and I'd hate to discourage developers from contributing / participating because what they are interested isn't a headlining item. I still think it is worth it though if it means we can focus and help push the group's initiatives forward (we'll get more done if, as you mention, we finish the high-prio things, rather than having 10 items in-progress). RE Phases:
This seems strangely limiting, I understand the intent, but we should always be open and receptive to changes that would make proposals better.
Often we don't have full browser implementer support (it might only be 1 or 2 implementers at first). Not sure if it is worthwhile to codify here if we're looking for full browser implementer support, or if a single one would suffice. Separately, I wonder if there is a step as part of, or between, 3 / 4 that involves writing WPTs. We have heard over-and-over that this is probably one of our best tools for pushing forward implementations. Even if these tests are just in-progress PRs, that would do a lot of good to show the group's investment in the platform, and that we have thought through the basic cases. RE Feedback Loops: RE Open Questions:
I think it might be valuable as part of closing a GH Issue that the author summarizes the open feedback / questions in the summary of the original issue. This could make it easy to reference and understand open items to tackle for the next phase (if that issue has not been created yet). Potentially a draft GH issue of the next status could accomplish this (if I'm understanding the process correctly). |
I think of the feedback loops as being outside of the meetings. So the 1 month time box is real calendar months from the date of opening the issue, or declaring it "ready for feedback". If there needs to be a discrete workflow status for "ready for feedback" I can definitely add that. I envision a world where we dont use the WCCG meetings to discuss/debate the features/specs, but that we use them more as a standup/refinement meeting where the main goal is keeping organized and not making implementation decisions/giving feedback about specs. To your point, I think it would be good to declare something like "this feature is ready for feedback, so go take a look" in a meeting, but more as a status update than to discuss the actual spec. Maybe this kind of thing goes in its own section in "non-workflow process guidelines"?
I hope that the fact that there can be unlimited things in the "ideation" status would mean that folks can still contribute and the group can still be giving feedback on all manner of new things. But I think that success in getting things shipped means not losing focus. I think we've seen that a few times this year where we will be discussing spec A and spec B will pop up out of nowhere and divert attention. One of my goals with this workflow is that doesnt happen except for occasionally when we all agree that should happen and its "official" and "on record" that we are switching focus instead of some hot new feature accidentally pulling focus away from other mostly done things.
Let me know if you have any ideas about how to phrase this better. My intent is that we always need to be clear about what to give feedback on. If something is constantly changing then when you come to some GH issue at a point in time, you dont easily know if its been changed since the last time you looked at it. That can cause swirl and make things take longer. If we can take the time to get these ideas a little more fleshed out before declaring "ready to go" i think that will help not only us but also implementers. I had a thought about adding a template for a spec/feature GH issue that includes a preamble note at the top that indicates the last time the content in the main spec comment was updated. Something like Note Timebox: 1 month : August 23rd That would indicate both the intended end of a feedback loop, and the last time it was updated. The idea being that when you make substantive changes because of feedback, you change the updated date also. I know GH shows you all the edits, but its kinda hidden in the little dropdown menu. One other thought is that we codify the practice of waiting until the end of a feedback loop has passed to make changes? If the original author puts up an idea, opens it up for feedback, waits a month without making any changes, collates ALL feedback from that month into a single set of changes to be made, makes the changes, opens the spec back up for new feedback based on changes made, etc. Maybe that will help us focus our feedback on stable things without having to worry that the spec changed the day after we commented on it?
I would think that just one would suffice. If we just get a single implementer, the others usually come along eventually. And if one implementer starts the prototyping process, that automatically puts that spec/feature into "Support mode" for us because we switch into being testers that verify the prototype implementation works the way it was planned to work etc. I dont actually know where writing WPTs goes, but my thought was that it would go as a task in the Implementer support phase. maybe thats the first phase? It might depend on whether or not the feature is WPT testable in the first place? I view writing WPTs as a task and not a discrete phase, but happy to hear alternate opinions.
I took this idea from my freelancing client contract work that I do sometimes. In the freelance world, you give your client 3 chances to provide feedback. That means that in each feedback period, they should provide as much feedback as they can all at once instead of trickling little bits here and there on and on forever and ever. At the end of a feedback loop the hope is that you have a lot of substantive feedback and can make changes to the workable item all at once instead of little by little, one comment at a time. The idea of having a maximum number of review cycles prevents endless critique/change. At the end of the 3 cycles, then the client should be happy because they should have used those feedback opportunities to refine and get closer to their desired result. Take open-styleable for example in our world. We could debate the workings of open-styleable FOREVER and never get any closer to a solution. If you limit the number of feedback cycles, then you are saying "we are not going to debate this forever" and if at the end of the maximum feedback loops you still havent arrived at community consensus, that is a good sign to go back to the drawing board and re-architect the feature/spec to break it up, make it smaller, refine it etc. Exactly like we are probably going to do with open-stylable. So establishing a baseline maximum number of times to review and refine helps us keep an eye on shipping or re-prioritizing—so that we can keep on shipping. |
|
I really like this document. Thank's for the job. I have one comment concerning the WPT. I think it would be a good idea to list all the WPT needed during phase 3 (WCCG Adopted) so that it will be easier for people to write them in phase 4 (Implementation support). What about the document format that will serve as a reference for implementers? Do we need to define a structure? I also think it would be great to have an area where you can quickly see the features under development with the link to the specs, the link to the WPT + progress (e.g. 17 written / 32), the champion, etc. |
Can we actually document all the WPTs that will be needed ahead of time? Or will the WPT tests needed be figured out as a part of getting to "Implementer Support" status? For what its worth, in this document, I'm only trying to outline high level states that some feature/spec can be in. I'm not trying to outline all the tasks that might need to happen to get a feature/spec from one status to another. I'm not sure where "write WPTs" fits in terms of this process, but I'm happy to add that as some entry/exit criteria for one of the states.
I think this is a great idea! Maybe a part of this process is to define a feature/spec template that we all follow so that each spec/feature document has the same structure and would be easy to follow from spec to spec. Do you have any ideas about what the structure of a feature/spec should be? |
|
Thanks for getting this started @michaelwarren1106 ! A couple thoughts from my end
Definitely +1 to to using GitHub projects. Perhaps tagging could even automate putting issues into the right column!? Can also +1 to using GitHub Discussions given their threaded nature, which may prove a nice starting point for an idea in the workflow, and then it can advance into an issue once it has a little more "shape". This may also alleviate the next topic (e.g. reserving issues for things the WCCG wants to champion to its fullest extent) 👇
Perhaps instead of a putting a cap on the group as a whole, maybe it could be as a cap per person / champion? Running with the agile theme here, maybe we do a soft limit of two WIP items per? In case something gets blocked or stalled out, or just needs time for review / feedback from the group, having something else for someone to work on in parallel may be valuable for motivated members? Basically echoing @JRJurman 's sentiments around not discouraging enthusiastic members, and thus combined with general guidelines for advancing items, there would still be a "gate" of sorts to ensure that all items cross the finish line with a reasonable amount of investment and detail. I could even envision cases where someone get a few things setup and then others more experienced in the space could take it over the finish line when it comes to implementations (maybe these don't have a library to validate it in, like in the case of our community protocols) or just have one-time window to get a lot of things done in a short burst of time. (Mostly just thinking out loud on this one but overall very much agree in spirit with limiting WIP, though acknowledging this is volunteer work, so take what you can get if you can get it heh 😅 ). Perhaps this is worth its own issue, but on the last call we inventoried all the related WC repos we operate in, and so not sure if we had a clear place to establish what ones are used for what purpose, and / or if there is any opportunity to consolidate, or at least document. (not sure what others think here) |
that’s a good idea! my main concern is to get and stay organized so that we can present ideas to the implementers efficiently and strategically. another goal is that a brand new spec/feature doesn’t come into existence then immediately pull resources and attention away from existing things. i dont have a ton of practical observation in the community group but i have seen a few times where a brand new idea will get created and then dominate discussion in the very next wccg meetings etc. process-wise i would say that’s generally not something we want? idea-wise and participation-wise it’s good for new ideas to get attention but there’s gotta be a balance i think. it’ll definitely be tricky no matter what we do thanks for listing out the repos! i definitely think we should at least document the reason/purpose each repo has and keep that documentation somewhere as onboarding for new folks to get oriented. should that be its own proposal or a work item on this one? |
|
I really like the idea of time boxes, it similar implies an owner of a discussion which I think is sorely lacking in the context of discussions we've had in the past. Limits feels...limiting. The implications are so close to what you get with time boxes, but I think can be alienating. We should limit the number of things in any "phase" to how many people we can get to actively own a discussion. For the actual workflow steps, I feel like the process isn't going to always be linear, many steps may be repeated over time to find the right solutions, and not everything that the WCCG should be discussing will need all of them. It's hard to say whether or not the stops in the workflow you've outlined covered everything, but an alternate set of stops (as food for thought) might include:
I think this is a great start! With all process, I find that iteration is needed over time, so once we come to a good enough version of this, we should apply it to an actual idea as soon as possible to start seeming the holes we've certainly missed. |
I came at the wip limits from the perspective of not overwhelming implementors when we get into TPAC type meetings, but that’s totally not to say that there’s a better way. imo either could be fine. historically we’ve had more features/specs than champions though. so i think the way we define the limits can be derived from whether or not championship of features (wccg attendance and membership) grows. if things stay like they currently are, we should limit by what doesn’t overwhelm implementors. if we find ourselves with lots of willing champions then we can limit by champions as long as that doesn’t overwhelm implementors? another thought about the limits is that there aren’t/shouldn’t be any in the ideation/feedback states. therefore anyone at anytime can be contributing features and feedback, and even joining up to champion something and help drive it. but i tend to think that implementors time and buyin is the real limiting factor and we will ship more regularly if we can find the right balance of wip things and implementors time/energy. but i love your additional statuses! i will definitely fold those into my changes after this feedback round! and you are 100% right that specs can absolutely go backwards and forwards and repeat states in their flow. the goal of the states isn’t only forward progress it’s just to document what is actually going on real time in a digestible way. so if things need to go backwards, they do and that’s 100% ok and expected. one other concept that came to mind in our last tpac meeting that i think we should get some kind of handle on is our expectations of where the majority of features that get implemented will “come from”. ie, do we think that most features browsers get for WCs will have traversed a flow through the wccg? or do we think there’s a path for WC features to land without the wccg getting that feature in front of implementors, presenting at tpac, holding face to faces and breakouts etc? if we think that the majority of features that get made do so by having gone through the wccg, the. we should strive to centralize the documentation where it makes sense to us right? like what typically happens with WC features that get contributed straight to whatwg/dom/csswg repos? do they tend to get worked on without wccg involvement? figuring out the role of the wccg in terms of shepherding these features is important imo. are we wanting to put ourselves in the position of being “responsible gatekeepers”? i don’t know if whatwg and csswg feel that way, but it certainly feels like nothing gets implemented in css without the csswg pushing it along. assuming i’m correct about that, is that something we want to model or not? |
|
Made an issue for discussing repos / orgs within our group - #100 |
|
Note If you're reading this thread and get to here, the original proposal above has been changed as of the date of this comment. Feedback below this comment will be in reference to the NEW version of the proposal in the main comment of this issues. All, I've finally gotten a chance to update this process proposal given the feedback from everyone! Take a look and give some more feedback! I took a lot of your suggestions and changed up the workflow phases a bit. I also removed the idea of WIP limits, but just noted its something that the WCCG needs to be mindful of so that we can focus on shipping and not lose that focus every time a cool new idea comes up. Thanks! |
It seems at odds with the fact that 1, 2 and 3 are probably all going to happen at the same time? I.e. use cases drive API design and some amount of refinement is always going to happen in the beginning phases. At least 1 and 2 seem like they can be part of the first stage? |
|
I guess maybe I should rephrase that section to say that a workable item skipping a phase should be intentional and called out somehow/somewhere? So in the event that 1, 2, and 3 all happen at the same time, then some folks should agree that the item meets the criteria for moving on? My intent with the not skipping section was that we always allow for these things to take shape as much as we can before getting them in front of implementers. I know that not every spec works this way because sometimes we bring ideas to implementers as a gut check before going the proposal route etc. But I think the process should be the baseline and we have exceptions where we need to. So, as a baseline I would still say that workable things shouldnt skip phases, then we have purposeful exceptions when they happen? |
|
I think it is reasonable to have 2 as a criteria for step 1. In general I would like to see some more guidance in how a proposal should look. Maybe an issue template? It seems plausible that the an issue will go through 1,2,3 "privately" before an issue is created. After that we have an "unofficial" feedback stage since the issue is open for comments before reaching the feedback official stage. So 4. is mostly a declaration that the first draft is finished and free to scrutinize for edge cases the proposers might have missed. |
|
I would love to make a proposal template! I think the problem is that proposals we might push on wont necessarily be created in our repo alone. There are proposals in WHATWG and CSSWG also and they would have their own needs/templates etc. We could certainly have a template for issues in our own repo, but that wouldnt necessarily extend to the other repos where specs sometimes come from that we push on/participate in. Secondly is the idea that the "project card" that represents a proposal for our tracking and planning purposes alone would exist as a second thing in addition to the primary proposal issue. Ideally there would also be a template for the project card, but I wouldnt imagine the actual details for a proposal living in the card details. I would imagine only links out to the actual details in the project card so its easy to find when we need it etc. |
|
Thanks for all of the work you have put into this, @michaelwarren1106! As someone coming back to WCCG activities after a hiatus, the proposed process looks very sensible, but I'm having trouble assessing how likely it is to "move the needle" on efficient iteration. With this in mind, I think it would be super helpful to flesh out the Background section with a concise but specific set of problems this process aims to solve, or objectives it aims to achieve, including examples where the lack of process seems to have impeded progress so far. Does that make sense? To be clear, I don't have any specific objections to what's being proposed; I would just like more context for gauging the likelihood of the proposal to solve the observed problems. |
|
@graynorton Thanks for the callout! I edited the main comment above and added an extra paragraph that outlines some more background and more of the goals around this process definition work. imo its mainly about all the wccg group members having a consistent and readily available grasp of the specs we're currently working on, what stages they are in (as we define) in order to be efficient about how things flow from idea to implementation through the WCCG. Up till now, at least in my own opinion, the workflow has been a bit ad hoc, and I think that defining it a little more will help us keep things organized and might help us get the good ideas shipped faster? |
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:
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
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
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.
The text was updated successfully, but these errors were encountered: