70 lines
3.1 KiB
Plaintext
70 lines
3.1 KiB
Plaintext
= Decision-Making Framework
|
|
|
|
== Proposal
|
|
|
|
Design and process decision proposals should be made to the `quarkus-dev`
|
|
Google group (https://groups.google.com/forum/#!forum/quarkus-dev[on the web]
|
|
or mailto:quarkus-dev@groups.google.com[over e-mail]).
|
|
|
|
== Bake time
|
|
|
|
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.
|
|
|
|
== Notification
|
|
|
|
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 https://quarkusio.zulipchat.com/#[the online Zulip chat].
|
|
|
|
== Issues and pull requests on GitHub
|
|
|
|
If a https://github.com/quarkusio/quarkus/issues[GitHub issue] or
|
|
https://github.com/quarkusio/quarkus/pulls[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.
|
|
|
|
== Disputes
|
|
|
|
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.
|