Create proposal_stages.md #12
Conversation
| ## Stage 6: Done | ||
|
|
||
| This is the final stage. All relevant subtasks and issues have been addressed. If there is additional maintenance work, this can be considered separate from the initial feature or proposal implementation. | ||
|
|
There was a problem hiding this comment.
Stage 7 : deferred/stale? This breaks the linear nature of the workflow diagram. This state is useful to show a proposal is hung up and no on is making progress on it.
There was a problem hiding this comment.
Is this state branched from a proposal that has yet to be accepted (e.g. not getting any clear vision or the contributor stops addressing feedback) or is it for work that was already accepted and in progress, however no progress is being made after a period?
|
|
||
| ## Stage 2: Ready | ||
|
|
||
| In this stage, the draft has received feedback from the community. It is considered to be in “ready for work” state. Tasks have been clearly defined and broken down into relevant sub-components and subtasks, sufficient such that a principal contributor may begin execution with clear direction. To move to the next stage, there should be a discussion/vote on the proposal’s priority, who will be the principal contributor, and the intended timeline for completion. |
There was a problem hiding this comment.
In this stage, the draft has received feedback from the community.
This is something that is highly unclear to me, how is this move triggered, if there is zero feedback ?
Or asked the other way around, how many replies, what quality of feedback is needed for the transition to ready ?
There was a problem hiding this comment.
Feedbacks from March 6th WG meeting:
in this stage the idea has received initial feedbacks and has been discussed by the WG.
The proposer should open a PR to add a design document for the idea.
The design document should be reviewed and approved by the WG participants
(TBD define roles, number of approvals, etc).
Eventually it will be merged into the repository.
This won't immediately indicate that someone is working on this item, but rather that the idea has been reviewed by us and is ready to be worked on.
There was a problem hiding this comment.
I generally agree that a PR to open a design document would be a good way to formalize the proposal and incorpoarate it in the WG documentation. Perhaps we could then create a separate issue type for tracking of merged (e.g. ready) proposals?
In the WG governance document (taken from the template), there are roles defined for reviewers and approvers. How do we feel about nominating folks (to include self nominations) to utilize these roles and facilitate the process for proposals?
| ## Stage 5: In Review | ||
|
|
||
| In this change, other community members/developers are reviewing the implementation and quality of the proposal/task work, with minor* changes, if any, that may be required for completion. To move to the next stage, all issues from reviewers have been addressed. | ||
|
|
There was a problem hiding this comment.
Agree - or it can be part of the review
- Get multiple companies to try the feature out
- Ensure it runs reliably in CI if it's something that is automated (i.e - it's not flaky)
- Ensure the documentation is sufficient for other companies to use the feature
There was a problem hiding this comment.
A common occurence I often see is that all "tests" may be passing, however the work may be still be blocked by reviewers based on how it is implemented. Perhaps we can fold testing requirements, CI, documentation etc. as part of the criteria for being considered Done?
|
@bpwilcox consider doing a newline in the markdown at the end of each sentence, to facilitate reviewing. |
|
|
||
| In this stage, the proposal has been accepted and is part of the ROS 2 Production WG’s project planning board. A principal contributor has been identified. Accepted proposals will be visible on the working group’s project roadmap. To move to the next stage, the principal contributor should be providing regular updates to the working group. | ||
|
|
||
| ## Stage 4: In Progress |
There was a problem hiding this comment.
Feedbacks from March 6th WG meeting.
At a certain point the proposal should also be discussed with the ROS 2 community.
The type of interaction should depend on the impact and type of proposal.
For example, for a proposal that modifies a single ROS 2 package, it may be sufficient to consult with its maintainers.
More complex proposals may require escalation to the broader community (discourse) and/or the ROS 2 TSC.
Getting feedbacks from maintainers shouldn't be a blocker to start development, but it should be done as soon as possible, for example inviting them to review meetings in the WG.
| The following stages are also intended to be used as github tags for tracking. | ||
| ## Stage 1: Draft | ||
|
|
||
| The draft stage represents the initial proposal of a project or task which has been formalised into a github issue for presentation to the community. To move to the next stage, this draft should be presented to the ROS2 Production WG and discussed in relevant channels (e.g slack, github, discourse, etc.), having addressed feedback about the scope, methodology, and tasks required to implement this proposal. |
There was a problem hiding this comment.
| The draft stage represents the initial proposal of a project or task which has been formalised into a github issue for presentation to the community. To move to the next stage, this draft should be presented to the ROS2 Production WG and discussed in relevant channels (e.g slack, github, discourse, etc.), having addressed feedback about the scope, methodology, and tasks required to implement this proposal. | |
| The draft stage represents the initial proposal of a project or task which has been formalised into a github issue for presentation to the community. To move to the next stage, this draft should be presented to the ROS 2 Production WG and discussed in relevant channels (e.g slack, github, discourse, etc.), having addressed feedback about the scope, methodology, and tasks required to implement this proposal. |
|
|
||
| In this change, other community members/developers are reviewing the implementation and quality of the proposal/task work, with minor* changes, if any, that may be required for completion. To move to the next stage, all issues from reviewers have been addressed. | ||
|
|
||
| ## Stage 6: Done |
There was a problem hiding this comment.
I'd add a rejected state to document what got rejected and why
Modify Governance Model
In this PR, I am proposing a governance policy for the advancement of proposals through this working group's project management and roadmap. These proposal stages are intended to provide a clear process by which the community can discuss, track, and execute work in this group.