search

inveniosoftware / rfcs

RFCs for Invenio.
https://rfcs.readthedocs.io
4 stars 15 forks source link

Decide on decision process for RFCs #1

Open lnielsen opened 5 years ago

lnielsen commented 5 years ago

There should be a defined decision process for RFCs to be either accepted or rejected. It's important that the process be as lightweight as possible while still allowing some structure.

The purpose of the RFC is to make it easier to collaborate together and ensure we have some minimal documentation about design decisions taken.

My current thoughts:

There should also be a way for how less technical users can get help to write up an RFC.

Please write your ideas/comments/suggestions for how the RFC process should work. Links to other RFC processes are also very welcome.

fenekku commented 5 years ago

Invenio Architects could take the final decision based on some principles

Yes, we should make sure a person (architect) with a wider perspective / vision on Invenio is in the loop.

inline with the code of conduct

Was "inline with roadmap" meant here? Phrasing the RFC in a decent manner is of course the encouraged way, but English may not necessarily be the submitter's first language and may explain the tone. Reviewers should account for that (massage or encourage submitter to mollify their language).

Decisions of architects could be appealed to the Invenio Governance

If the RFC is rejected, then a closing comment with justification has to be provided. Submitters and reviewers probably took time + effort to discuss the problem, so a nice explanation would be appreciated. Also, the RFC or issue may be revisited later and it's important to be able to go back and re-assess the reasoning behind the rejection.

appealed to the Invenio Governance

Sounds like a court decision :smile: which may be too heavy. If the context changes since the initial rejection, then a closed RFC should be fair game to revisit. Should a new RFC be made or old one re-opened and edited? A new commit would help preserve decision history in latter case.

defined timeline for RFCs

Yes, getting back to people on time (no matter outcome) is key to projecting a respectful/active community. Within a week(?) of submission, a "core" team member should get back to the submitter (even if only to acknowledge lack of time to deal with it in the coming days). There doesn't have to be a time frame in terms of implementation (like EmberJS), but when it is implemented a link to the PR finalizing this change should be made. This leaves the question of how "core" team members are alerted. Using an @team in the PR? Having members subscribe to the rfcs repo? Bot? EmberJS has a breakdown of teams and their responsibility so that submitters know which team to contact.

addition

Something like the following from ponylang rfcs about the possibility of meetings would be nice:

While the RFC PR is up, we may schedule meetings with the author and/or relevant stakeholders to discuss the issues in greater detail. A summary from the meeting will be posted back to the RFC pull request.

lnielsen commented 4 years ago

New thoughts

It takes long time to discuss RFCs, and there's a risk that RFCs hang in PRs for a long time. This has an impact:

My proposal would be to simply merge RFCs as fast as possible (i.e. once it's readable and keep the state as text inside the document. E.g having a header like this:

- Start Date: 2020-03-11
- RFC PR: [#<PR>](https://github.com/inveniosoftware/rfcs/pull/<PR>)
- Authors: Lars Holm Nielsen, Alex Ioannidis, Nicola Tarocco
- State: DRAFT