Skip to content

Latest commit

 

History

History
276 lines (226 loc) · 14.7 KB

process.md

File metadata and controls

276 lines (226 loc) · 14.7 KB
Raw

Agenda, proposals, projects, and teams

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.

Getting on the agenda

In order to better plan and facilitate meetings, Security TAG has three ways in which a topic may be added to the Agenda for planned meetings.

In order to best manage the group's time, consider your topic and the audience, and select accordingly. If you are unsure, reach out in the #tag-security-governance channel.

Topics and updates

We expect our members working on projects and members of groups to periodically provide updates to the TAG as part of our longstanding meeting format. If you are currently working on a project or a member of a group, your updates are already embedded in the format. If they are not, reach out to #tag-security-governance to have them added.

If you have a topic or point of discussion you which to raise which is not:

  • already part of an update
  • not a proposal or suggestion

but, as part of a working session is:

  • seeking input
  • probably no more than 15 minutes of discussion
  • adhere's to our governance and code of conduct

please add it to the Agenda for a WORKING SESSION with a [PENDING] prefix on the topic, put your name next to it, and let us know by dropping note in the #tag-security-governance channel. We will provide feedback if necessary and a member of the leadership team will help add it to the agenda and remove the [PENDING] prefix.

Example: [PENDING] Security discussion on why R. Raccoon should be friends with Phippy — R. Raccoon

We want to foster ad hoc discussions during working sessions, but also recognize some discussions may take slightly more time than a general question or informative note.

Raising an Issue

Anyone is welcome to raise an issue either as a suggestion or as a proposal. These will follow the process described in proposals and suggestions.

Suggestions, proposals, & presentations

Before creating an issue, review the existing issues to determine if something already exists that covers or is closely related to what you want to discuss or present to the group. We have several types of issues that cover different scenarios.

Presentations

We love to have presentations about various efforts our members and the greater community are working on. They allow us to gain insights into new challenges, upcoming trends, and often inspire our group to take on new projects. It is important that any content presented to the group must adhere to our guidelines.

Presentations require a presentation issue to be created. Please fill this in as completely and accurately as you can, providing multiple dates for presentations is ideal.

Once a presentation issue is submitted a Security TAG representative will be assigned to or review the issue to triage the request. Once triaged, the Security TAG representative will perform due diligence on the issue to ensure it adhere's to our requirements for presentation content. If the requirements are met, the Security TAG representative will then add the topic, link the issue, and provide the point of contact and themselves on the Agenda.

We strive to have no more than two presentations in a given meeting, but prefer only one to ensure we have ample time for lively discussions.

Suggestions

Suggestions are an easy way for someone to suggest something to the group for which you do not intend to be the project lead of. It is important that you bear in mind when submitting suggestions that if there is no volunteer to lead the work will not happen. Mentoring and co-leading are available to anyone unsure or interested in becoming a project lead, often suggestions have a limited scope of work and are ideal for individuals looking to stretch their professional skills.

Proposals

Proposals are ideas that are intended to become projects, where the submitter explicitly volunteers to be the project lead. If a proposal is submitted that does not have a project lead intent checked, it will be converted to a suggestion during triage.

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. Review existing issues: Look at the existing issues and determine if any already exist. If an issue already exists that is marked as a suggestion but you are interested in leading, comment on the issue and reach out in the #tag-security-triage channel to bring attention to it. Skip to ask for collaboration.

  2. 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 and be sure to complete the project lead intent checkbox, or use the suggestion template if you would like someone else to lead the effort. Try to complete the template as much as possible.

  3. 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, if so, refer them to the issue which has content on discussions/meetings where the issue will be introduced or where to stay tuned for more information. Provide the issue link and encourage any 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 depending on the level of interest. It is sometimes recommended to schedule an initial scoping meeting with interested individuals to help refine the scope. We recommend using a doodle poll or other polling mechanism in the slack channel to determine everyone's availability. If interested in scheduling a meeting but don't have a mechanism to conduct the meeting, reach out to the leadership team to have a zoom meeting set up.

    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 -- usually the author of the proposal.
    • 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.

    Once the scope is defined and a definition of done is described, the nominated lead(s) needs to seek out a Chair or Technical Lead to sponsor the proposal.

* The sponsor reviews the scope and definition of done, determines if it is
  in scope of the roadmap, and updates the issue with the scope and
  definition of done.
 * 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.
* The sponsor presents the proposal for discussion at the next leadership
  meeting to determine roadmap concurrence and group workload.
 * Roadmap: determine there is interest and strong roadmap alignment,
    determine the workload of the group and existing bandwidth to ensure it
    is driven to completion. If the proposal does not fit in the roadmap, it
    does _not_ mean that it cannot be worked.

  1. Accept or close the proposal.

    A) Accept: The sponsor will confirm the project lead(s)and assign themselves and the lead(s) to the issue, 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: Closure may occur as a result of lack of interest (stale for 90 days without meaningful activity) or as a result of a consensus to close (resulting from any number of factors). If a decision was made to close the issue, 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: If the issue is in scope of the roadmap but the group cannot support the additional workload, the issue will remain a proposal and be placed on a roadmap board as "planned and scheduled" with an anticipated quarter to begin the work. The roadmap is reviewed quarterly.

Active projects

  1. Track progress. As long as work is ongoing, progress should be tracked both in the Issue, to the sponsor, and reported on periodically in meetings.

    • Someone working on the project will attend weekly meetings to answer questions and provide an update. In case of absence, ensure that github issue 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 Issue that shows what has been done and what work remains and should include a retrospective. The issue should also include a link to the meeting notes for the work.

  2. Present the work in progress. Often, prior to the completion of the work, it is beneficial to present the work to the broader group to gather a final review, solicit additional feedback, or seek recommendations. These should be placed in the planned meetings section with a project member as the point of contact to present.

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

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

  5. Vote, if required. In some cases, there's consensus to accept a PR, and a vote is not required. If there’s no consensus among the group, a formal vote is required. A comment will be left on the PR 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).

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