Skip to content

Latest commit

 

History

History
39 lines (25 loc) · 3.32 KB

approval-system.md

File metadata and controls

39 lines (25 loc) · 3.32 KB
Raw

GitHub & P2 self-approval system

To avoid getting issues stuck waiting for approval, the Sustainability Team has established a system whereby each contributor can manage a deadline of minimum 2 weeks for accepting its own changes after public communication.

How does this self-approval system works

  1. Make a change or a proposal. It may be minor contributions like a Github Pull Request or the structure of a documents, for example. Check more examples below.
  2. Announce it in the team meeting. It is important to make it easy for everyone to be aware and have the opportunity of leave their opinion. For that purpose:
    • Ask for a topic to be included in the next meeting (if not related to an existing one) so that you can announce your contribution, explain it and ask for feedback
    • Use GitHub or P2 (ask the Team Reps in this case) to have a place, if there is not already one, for contributors to give feedback in an accessible and lasting way.
  3. Establish a deadline. Ideally, it’d be two weeks from the moment you share your contribution at the team meeting. During this time, contributors will have time to leave their comments and discuss about your contribution.
  4. Move forward. You can go ahead with your contribution in two ways:
    • Flow with the feedback. Depending on the type of proposal you have made, the discussion can lead the thing to a different solution or even to refuse your suggestion, to name a few possible scenarios. Forget or reschedule depending on the case.
    • Self-approve your changes. If no one shares their thoughts, everybody agrees with your proposal or the feedback does not represent a significant change to its nature, you can assume that nobody has any problem with it and approve it yourself when the deadline is up.

When to apply this self-approval system

👍 This system is intended for minor contributions or those that have been discussed previously and everyone agrees.

Here are some examples:

  • Changing a title or the wording in a document, like the Handbook or any team documentation.
  • Creating a structure for a document that the team already agrees to create.
  • Creating new GitHub issues.
  • Adding or updating content of an existing project in the GitHub repository.

👎 The system is not valid for major changes that significantly affect the team and its operation.

This changes must have the explicit approval of a significant portion of the contributors.

As we are still testing what works best for the proper functioning of the team, there is no strict definition of the cases in which not to use this system yet. This is why we appeal to individual common sense in favor of the community as a whole.

If in doubt, bring up the subject at a meeting or directly ask the Team Reps before approving any change.

System evolution

You can find the formal decision post for this self-approval system in the Sustainability Team blog.

As stated there, this system can be subject to change depending on how the needs and dynamics of the team and its contributors change. Changes will be communicated in P2 and updated here as soon as they are official.