In the previous team meeting, it was suggested to establish a deadline system for approving changes or contributions when it’s not clear who or when move forward with them.
How the system works
As we often get stuck waiting for approval, we can manage a deadline ourselves to accept our own changes as follows:
- Make a change or a proposal. It may be minor contributions like a Github GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ Pull Request or the structure of a documents, for example. Check more examples below.
- 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. So that purpose, we could:
- 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, and
- use Github or P2 P2 or O2 is the term people use to refer to the Make WordPress blog. It can be found at https://make.wordpress.org/. (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.
- 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.
- 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. So you can approve the thing yourself when the deadline is up, and move on.
When to apply this system
👍 This system is intended for minor contributions or those that have been discussed previously and everyone agrees, but no one has offered to make them a reality. Just 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.
- Create new Github issues.
- Add or update content in the Github repository of an existing project.
👎 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.
There is no strict definition of the cases in which not to use this system for now, because we are still trying to test what works best for the proper functioning of the team and because 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.
Endorsement of the measure
This proposal has been suggested and supported in this Slack meeting. However, you can share your thoughts about it here. You can also suggest do/don’t examples to help contributors to be more clear about when to use the system.
