Skip to content

Latest commit

 

History

History
144 lines (120 loc) · 7.64 KB

process.md

File metadata and controls

144 lines (120 loc) · 7.64 KB
Raw

Proposals, projects, and team

In addition to the activities driven by the CNCF Technical Oversight Committee, the work of the group often originates from group members with ideas on how to reduce risk in cloud native applications in alignment with the charter of the group and of interest and importance to the community.

This document explains how we transform ideas from our community into projects with a defined set of deliverables or a team to focus on a larger stream of work that may involve one or more projects and activities.

Creating, discussing and accepting proposals

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.

Proposal process

  1. Raise an Issue:

Create an issue that outlines the problem to be solved. Use the proposal template if you are interested in leading the work, or suggestion template if you would like someone else to lead the effort. If possible, include:

* The customer impact of the problem
* The scope of the work required

  1. Ask the group for collaboration: Rather than immediately beginning work on a solution, bring the issue up for discussion. The following guidance shows common steps, though communication often happens in different sequence. The key outcome is that there is opportunity for input across different channels, with thoughtfulness to accessibility across timezone and communication medium. We also encourage outreach outside of the group, when there are experts who might share insights (via invited presentation) or wish to get involved.

    A) On slack, share the issue link and ask whether others are interested in the problem and have feedback on your proposed solution or activity.

    B) Choose an upcoming meeting where you or another group member who is interested in working on the project is able to attend, then add the issue to the meeting agenda: include a link and the name of the person who will present the proposal in the "Planned Meeting" area of the [meeting notes][https://github.com/cncf/tag-security#meeting-times]. Then at the meeting:

    • The presenter should screen share the github issue (or ask the meeting facilitator ahead of time to do so) and explain the motivation, expected outcome, ideas that they have for how it might happen, and ask if others have ideas or questions.
    • After a short discussion, people should be invited to chime in on the github issue and also mention of they are interested in collaborating. This ensures that solutions are created with multiple perspectives as well as verifies there is community interest and energy to work on the proposal.

    C) Discussion continues in the github issue for at least one week, usually over multiple weeks or sometimes months.

    The outcome of this conversation will be:

    • Scope may be refined (or questions from the group may need follow-up in order to define the scope)
    • 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 project with a defined deliverable or and on-going stream of work -- the latter would typically be proposed only after at least one, usually multiple, projects have been completed.
    • At least one person is recommended or nominated as a potential lead.
    • Those interested in working on the solution comment on the issue so coordination may begin and set up time or expectations with others to begin work.
    • A Chair or Technical Lead proposes this as a roadmap proposal or agrees to act as a "sponsor."
      • Sponsor: takes responsibility to ensure that progress is tracked and that outcomes are reported to the group, including proposing to close the issue if there is not sufficient activity to sustain the effort.
      • Roadmap: determine there is interest and strong roadmap alignment, but that there is not enough bandwidth to be confident that this work can be driven to completion.

  2. Accept or close the proposal.

    A) Accept: assign to the Sponsor and the Project Lead(s) working on the effort, with members interested in contributing noted in the issue descriptions, along with information about expected duration, milestones, scope, and anticipated deliverables. An accepted proposal becomes an active project (see below) and the "proposal" label is removed, the "project" label is added and it is added to the backlog.

    B) Close: a github comment on the issue should note the reason and link to discussion minutes (when decision is reached at a group meeting) or at least two members of the leadership team should be noted in agreement (which may include the person who closes the issue).

    C) Roadmap: the issue will remain a proposal and be placed on a roadmap project board. The roadmap is reviewed quarterly.

Active projects

  1. 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 and should include a retrospective.

  2. 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.

  3. 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.

  4. 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 attendance as recorded in the public minutes).

  5. Support the project going forward. Some projects require sustainment and maintenance to ensure continued relevance for the community. When work is completed, a new issue and corresponding pull request should be created and describe the expectations, plans, and ideas for on-going work. It should include historical information and guidelines for contributions and maintenance in the README for the project artifact's folder.