Decision-Making Framework

Design and process decision proposals should be made to the quarkus-dev Google group (on the web or over e-mail).

Any significant design or process decision should "bake" for a minimum of 2 regular working days before becoming policy. If this time elapses with no discussion, this should be considered to be assent - with a few caveats. This allows things to move along without new ideas being stuck in an idle "limbo" for weeks and weeks waiting for an OK.

When proposing a design decision, it is important to ensure that the maintainer(s) and contributor(s) of any impacted areas are aware of the decision. If a design proposal impacts a system and the maintainer has not responded (even just to say "OK"), then it is the responsibility of the proposer to ensure that they are not on PTO (vacation) or anything of that nature. The proposer should make a reasonable effort to contact the maintainer(s) and significant contributor(s) of the given area and ensure that they’ve at least seen the proposal. To streamline this, it’s a good idea for such maintainers to give their quick OK to a proposal on a timely basis.

In cases where it is unclear to the proposer who is responsible for a given area, this should be stated in the proposal so that the responsible person or people can be found.

For a process decision, the same rules apply, except that the "maintainers" of this "system" should be considered to be the project lead(s). Again silence means assent - but only if they’ve seen the proposal.

It is the responsibility of all maintainers to stay on top of design proposals, even if just to respond and say "I need time to think about it" before the 48 hours expire.

Notification may take place over the Google group or e-mail list, or over the online Zulip chat.

If a GitHub issue or pull request is created which proposes a design change, then it should be labelled triage/needs-decision, and the corresponding discussion should then be held on the Google group as explained above. A link to the discussion should be placed in a comment of the issue. Such pull requests should not be merged, nor issues resolved, until the design decision is resolved according to this process.

Because good ideas can come from anywhere, anyone may propose a design change; likewise, anyone may dispute a proposal. It is the responsibility of all parties to participate fairly and respectfully.

In the case of unresolvable disputes, the final decision rests with the project lead(s); it is their responsibility to ensure that they are informed on the details of the decision before ruling. The project leads are encouraged to facilitate resolution among the disputing parties before resorting to an executive ruling, but at the end of the day the project needs to move forward and so this should be kept in mind.