Hello, We are still maturing as a community and the process on how to decide important things for the entire community needs to be cleared up. After my previous email about getting things done several good ideas came up, it raised some good comments and questions both off and on list. To clear things up we need to be sure that we are on the same page to bring trust into the community and remove doubt.
There is also some overloading on the terms. While you can for example propose in any context. A proposal for the community, that can be acted on, is an email thread with the [PROPOSAL] in the title. I took the process from other Apache communities. This is influenced by how I see things and I am not the boss here. We can customise it to our needs. If I got something wrong I hope our mentor can correct us. *Each item is driven by an email thread in this list.* *[DISCUSSION]* Free speech, no commitment, any idea is welcomed. Important to know is that no decisions can be made. *[PROPOSAL]* Mutable. Who starts the proposal leads it. Make a wiki page for the proposal and link it in the start. People commenting can request changes, if approved the proposal wiki is edited to maintain the latest. The person who started the proposal thread has to know how to get resources and what the limits of those resources are. For example deadlines, motivation, skill or time issues. Same as any task in any company. Proposal creators should not agree on anything they can not deliver. Porcelli made a pretty good template to use when making a proposal. - Problem Statement: Clearly define the issue being addressed. - Action Plan: Outline the steps to address the issue. - Commitment: Specify who will take ownership of the action plan and a rough timeline for execution. If you absolutely disagree, make a countering proposal. But know that you have to find the resources for implementing it, better to try and compromise with the original. You can offer help. No final decisions can be made, but +-1 can be used to signal voting intentions. +-1 at this stage is not binding, you can vote differently. *[VOTE]* Immutable. If there was a proposal, take a timed snapshot of it and add it into the thread. Voting is done here, decisions are made here. If votes pass the thread is a signed contract that everyone agrees. -1 votes do not cancel the vote unless it is a vote for a release. When PR is done if it does not follow this contract it can be challenged. Vote does not have to have a proposal in advance, but it can help to get the best result. No changes can be done during a vote. You should not need to scroll down 10 emails to see what was agreed on. *Things that can happen.* Example is the upcoming documentation proposal/vote, discussion was already done. Vote does not pass. A countering proposal would pass votes, but there is nobody to work on it. We end up with no documentation. The community did not agree on creating them with the resources at hand. A discussion item like the monorepo keeps coming back in discussions. These cycles reduce productivity. We make a vote if we want one or not. No reason to bring it up unless you feel like a revote changes the result. Jason mentioned that in the past this location was suggested as the wiki location. https://cwiki.apache.org/confluence/display/KIE Hoping to move us forward. Toni
