[RFC] Discuss the details of setting up an RFC process

[heather999]

Summary

We would like to try out the RFC process as utilized by the DM/Project and discussed on Slack.

Description

We need a better way to reach consensus and to encourage discussion on a variety of Computing issues. The RFC process seems like a sensible way to proceed. This repository is an attempt to mimic the Project's RFC description. There are some things to sort out as far as what body would serve as our "Change Control Board" if consensus cannot be reached. If we are talking about DESC Computing, that may rightly involve the Computing WG conveners and the Computing Coordinator and Deputy. All should feel free to comment and offer suggestions about how to best handle the procedure from RFC creation through implementation.

Planned End Date

Monday, July 12, 2021

[JoanneBogart]

For me, a little flowchart in the README, showing the different paths an rfc can take via addition or removal of labels (and perhaps other actions) would be very helpful.

[JoanneBogart]

When a proposal is escalated, does that or might that involve changing the planned end date? Otherwise escalation doesn't seem to buy you much. The section "Escalate a RFC" needs to say more about the procedure.

[johannct]

We need a better way to reach consensus and to encourage discussion on a variety of Computing issues. : I give to Computing a restrictive meaning, unless you meant here the CO group. We deal with any requests that would impact DESC software system in a global way.

[johannct]

as our "Change Control Board" if consensus cannot be reached. : I was under the impression that the point of "lazy consensus" is that if it is not reached, the RFC has to be withdrawn. CCB is here to give a go to implementation based on some operational constraints that may have not been taken into account while reaching lazy consensus, but would defer to the experts discussing the RFC for actual relevance of the RFC, so consensus has to be reached before the CCB is called in IMHO. And as I mentioned on slack in my comments to the README, Operations absolutely need to be called in the CCB

[johannct]

@JoanneBogart Agreed about "escalation" fuzziness, as mentioned in my comments on slack. The "planned end" is to reach lazy consensus though, as far as I understand. Escalation occurs afterwards. So planned end is just the deadline before considering that no objection has been raised and that lazy consensus has been reached. Once consensus is reached, the label "adopted" makes the planned end useless. How to capture the time schedule to get CCB approval is another business though, and of course timelines for implementation is captured in the different issues relevant to the RFC ilplementation

[JoanneBogart]

The "planned end" is to reach lazy consensus though, as far as I understand. Escalation occurs afterwards.

@johannct I don't think these steps are sequential. The text in the README has an "either...or":

the RFC is either labelled proposed (that is, it has not been escalated) or approved (it has been escalated and subsequently approved by some TBD decision making body);

But this is just the original DM way of doing things. We need to decide what we want.

[johannct]

right but this is only due to the fact that some RFC in DM fall directly under CCB scrutiny. I would contend that we want to simplify all that, at least to start with, and have something very sequential. The only fork being adopted/withdrawn.

[heather999]

Switching between Slack and here is a bit tiring :) Coming to this comment from Johann. This is suggesting to modify the README to include "Proposing a new scheme or methodology that has broad consequences within DESC" ? I want us to be clear what areas are covered by RFC. By DESC Computing I do not mean the CO WG - but this needs to be stated more clearly. I don't know that we are proposing RFC to cover analysis or pipeline methodology, for example .. it could cover those things but we're not addressing that right now and I want to be sure how we frame this is understandable.
So I'm happy to add a reworded version of: Proposing a new scheme or methodology that has broad consequences within DESC

[heather999]

Next comment from Johann

The requestor must be especially careful about not making irreversible changes in the "lazy consensus" time period unless they are absolutely certain there's a general agreement on the stated course of action. : this reads as a surprise to me; it seems to imply that down the line, once the lazy consensus is reached, it is the initial requestor who is expected to do most if not all the job. Am I reading correctly, and if yes is it really what we want to imply? In the case of Rubin DM it might be fair, as they are formally a team of developers.... But in the case of DESC we want any member to feel empowered to make RFC even if he/she does not believe he/she can implement it on his/her own..... We are a science collaboration, not a software team

We need to better define the difference between a "requestor" and an "assignee" - since they may not be the same person. The requestor may not be the one best able to handle the RFC discussion and any implementation if the RFC is approved. The README should be updated and the template changed to allow the requestor to indicate that they are not the appropriate assignee. It would then be up to the CCB to step in to either name an assignee or that the RFC should be withdrawn.

[heather999]

Next comment from Johann

In the same spirit as the comment above and proposal as well as a "Planned End" date for comments. may perhaps rather be and proposal as well as a "Time limit before it becomes a road block" date for comments. My worry being again that someone within DESC may have a RFC in mind with some consequences if it is not resolved and implemented, but is not in power to decide of the duration of the comments from the CO/PS team etc....

My response

My worry here is that the typical 72 hours or one week seems like an appropriate and already expedited amount of time. "Time Limit before it becomes a road block" could result in time limits that are really too long to be useful. If someone needs a decision less that 72 hours - well.. I'm not sure that is really in the realm of possibility.

Johann's response

yes indeed. Still the requestor is not the person in charge of defining the "Planned End" time, as the latter is what the dev team will judge reasonable before lazy consensus is acted. Likewise the requestor will not necessarily be in charge of implementation in our context

I would still like to keep the "Planned End" relatively simple and not first require some discussion with the dev team or the CCB to figure out how long a discussion needs to be open. If the requestor is the "assignee" they should be able to determine a reasonable "Planned End". If the requestor is not the assignee - then that assignee could modify the "Planned End", which should really never be shorter than 72 hours I think, to allow people time to respond.. Maybe that is sufficient.

[heather999]

I added an initial flowchart accessible via the README

[johannct]

Following discussions with Jim, who expressed worries that the loose structure of DESC organisation would not easily acommodate a too strict process setup, Heather and I decided that we would move to something more of a forum here, as a starter. We will reopen this issue if defining a stricter process to handle RFC becomes a necessity or a consensual wish.