[Proposal] Well this is basically what we usually do most of us, but anyway. I agree with this but the commitment. If you propose you commit (you cannot delegate). The reason behind it is to avoid the existence of "coordinators", "architects" or two "contributor classes" here. I mean that this could lead to the existence of people who do not contribute to any artifact or deliverable, defeating the idea of contributors in the community. We are basing the approval of contributors on the pull requests and therefore added value in any of our repo/web page or whatever; the way to avoid people just talking but not doing is removing this idea of commitment or delegate. I strongly disagree with that definition. If someone proposes something independently if it is one person and then a whole group of people doing it you have to do it.
If you set a -1 you need to specify why. This could lead to different outcomes - no go (this does not add any value to the project or doesn't have merit). For instance, somebody wants to remove spring boot support in the project. (that is against the overall goals of the project) - total disagreement with the implementation. Agreed with the problem statement but not with the way it is going to be delivered. The technical merit should rule here (more fit to the overall view of the project, better fit in the architecture, dev support friendly, sustainability in the long term... etc...) - partial disagreement. Things that should be removed or changed and why. [VOTE] You are here going against the apache voting process. https://www.apache.org/foundation/voting.html In some cases like code changes. -1 is a veto. We cannot redefine the process. (That is what I understand from there) [Additional things to consider] Another thing to take into account here is the scope. This is really hard because sometimes community members might try to include extra things. I would say that the rule of thumb is that the proposal should be self contained and not add anything extra that could be removed without affecting the implementation. For instance; let's say I want to include the docs in the CI pipeline and for that reason I say in the proposal that I want to move the docs to the kogito runtimes. That last thing should be considered "illegal" as if you remove "the move" it is still possible to do technically adding to the CI pipeline. Cheers :) El mié, 29 ene 2025 a las 12:09, Toni Rikkola (<[email protected]>) escribió: > > 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 -- Saludos, Enrique González Martínez :) --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
