From 35c23aee9d623204060f88f0bfe2106b2bd9dd55 Mon Sep 17 00:00:00 2001 From: "David M. Lloyd" Date: Tue, 9 Apr 2019 17:38:26 -0500 Subject: [PATCH] Decisions framework --- DECISIONS.adoc | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 DECISIONS.adoc diff --git a/DECISIONS.adoc b/DECISIONS.adoc new file mode 100644 index 000000000..312c24dda --- /dev/null +++ b/DECISIONS.adoc @@ -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.