Each proposal is unique and might deviate slightly from the process below. For example, a small addition may not require completion criteria. In general, we encourage the process below to be followed to ensure that contributions are in line with the mission and charter.
-
Raise an Issue: Create an issue that outlines the problem to be solved. If possible, include:
- The customer impact of the problem
- The scope of the work required
-
Ask the group for collaboration: Rather than immediately beginning work on a solution, bring the issue up for discussion at a meeting, explain it, and ask if others are interested in collaborating. This ensures that solutions are created with multiple perspectives. The outcome of this conversation will be:
- The group agrees that this problem is appropriate scope Group.
- Criteria for completion are added to the issue that include a "definition of done", ideally with validation by the target audience. Also note in the issue if it will be a time-bounded or on-going project.
- At least one person is tasked with creating a solution
- Those interested in working on the solution either begin work or set up time or expectations with others to begin work.
- A Chair or Technical Lead agrees to act as Representative, which means they will take responsibility to ensure that progress is tracked and that outcomes are reported to the group or propose closing the issue if there is not sufficent activity to sustain the effort.
-
Accept or close the proposal. Accepted proposals will be assigned to the Representative and the active members working on the project should be noted in the issue, along with information about expected duration and milestones. If a proposal is closed, it should note the reason and link to discussion minutes.
-
Track progress. As long as work is ongoing, progress should be tracked both in the Issue and reported on periodically in meetings.
- Someone working on the project will attend weekly meetings to answer questions. In case of absence, ensure that github issues is updated and another member of the group who can attend the meeting is familiar with progress in case questions arise.
- It's strongly encouraged to include a checklist in the Isssue that shows what has been done and what work remains.
-
Pull Requests. Completed work should result in a Pull Request (PR). At minimum, an update to one of the group documents or roadmap indicating that the work was done. Typically projects will result in an artifact that will contribute to the information in this repository.
-
Discuss the work at a meeting. If an objection to a PR is made either in a comment of the PR or during a meeting, the person making the objection and the person making the proposal will be given time to present their view at the next meeting. If there are not objections, or if all concerns have been addressed, and the Pull Request has been stable for 24 hours, a Chair will add it to the agenda for an upcoming meeting. Ideally, members who contributed to the project will attend that meeting to present their work or answer questions.
-
Vote, if required. In some cases, there's consensus to accept a proposal, and a vote is not required. If there’s not consensus among the group, a formal vote is required. A comment will be left on the proposal prompting members to vote and indicating the time the vote will close. Only one member from each company should vote. Members will vote by leaving a comment in the Pull Request to indicate their vote for or against. Members will have a week after the vote begins to leave their vote. Quorum is taken to be 2/3 the number of companies who have been active in the past month (via issue comment or meeting attendace as recorded in the public minutes).
-
Support the project going forward. Some projects require ongoing support. When work is completed, the body of the Pull Request should specify if it's expected to require on-going support and if so, who will maintain it.ccept