jlengrand/quarkus
1
0
Fork 0
mirror of https://github.com/jlengrand/quarkus.git synced 2026-03-10 08:41:22 +00:00
Code Issues Packages Projects Releases Wiki Activity

Decisions framework

Browse Source
This commit is contained in:
David M. Lloyd
2019-04-09 17:38:26 -05:00
parent df9ea12867
commit 35c23aee9d
1 changed files with 69 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

69
DECISIONS.adoc Normal file
View File

@@ -0,0 +1,69 @@
= 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 `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.