Discussion: improve RFC process

[ashfurrow]

In Slack today, starting here, there was a discussion around the usefulness of Peril and Danger that led to the realization that the RFC process is currently inadequate. Developers expressed that the RFC process was opaque and too top-down. There were also concerns raised that the RFC process currently excludes (and fails to include) remote developers.

#38 clarifies the existing RFC process, but we should have a deeper discussion to make sure that everyone at Artsy feels that they're included in the process.

As a refresher, the RFC process currently is:

• Someone opens an issue on this repo that begins with "RFC: ", and that causes a message to be posted to Slack's #dev room.
• The RFC proposer announces the RFC in a weekly dev standup.
• At least a week goes by for discussion.
• Based on the outcome of the discussion, the RFC is implemented in a pull request, which is also open for discussion.

Here are a few questions to kick off the discussion:

• Is there anything missing from the RFC process? I suggested adding a reminder to Slack, for example.
• How can we further empower individual engineers to participate more in discussions and to propose their own RFCs?
• How can we make sure that the RFC process actively includes all team members, with a focus on remote folks, but also includes everyone in terms of seniority or team membership?

If you'd like to express an opinion privately (this repo is open source and public) please don't hesitate to reach out privately to me on Slack.

[cavvia]

As a remote developer, I don't have an issue with the RFC process and I was aware of it, as it has been mentioned in our weekly standup before. The minor annoyances I have with the Danger config on certain repos are probably easily remedied simply by editing a Dangerfile - I would simply be interested in disabling certain checks on a project-per-project basis.

[jonallured]

Chiming in here as another remote dev...

I would echo @cavvia's comments above - I'm satisfied with the RFC process and have made some comments on various ones that caught my eye. On the subject of Danger's feedback in general: if I don't agree, I usually just ignore it, haha.

(I'm looking at you CHANGELOG warnings 😄 )

[alloy]

As another remote dev, I’m happy with the RFC process as it is, I just haven’t had the need to file one yet.

Like @jonallured, I don’t treat warnings as errors.

[izakp]

I like the RFC process in general - I made a mistake in overlooking it even though it was mentioned publicly and even personally to me in regards to my comments on Danger's spellchecking feature before. In this case the spellchecking feature went through without my attention / feedback.

I think the part of the process to focus on would be to not simply wait a week to solicit feedback, then move forward with implementation, but to do more to solicit feedback from other team members. I think @ashfurrow your suggestion of reminders in Slack, perhaps that an RCF process is closing is a good feature to increase visibility. I also think voting to abstain would give the RCF proposer / implementer a better overview of how much consensus / attention the RCF generates.

However, dealing with RCFs as such goes a bit out of scope for Danger as an open-source project, and has more bearing on how we work with it internally. I am not sure what we can do to satisfy both these facets - updates to Danger core, which may suit its use in other contexts versus our specific context. Perhaps @orta you have some insight as the project's creator with how you see this... Does Danger in itself express what we feel as core practices, or is it somewhat separate from our organization in terms of its design, and do the rules we write in our Dangerfile configs express this?

On a side note @jonallured I also ignore CHANGELOG warning but feel I shouldn't :/ In this sense I feel like it's a good facet of Danger telling me to improve my practices. I don't treat them as errors but as reminders as such.

[orta]

Does Danger in itself express what we feel as core practices, or is it somewhat separate from our organization in terms of its design, and do the rules we write in our Dangerfile configs express this?

Danger provides no rules or abstractions, only the ability to create them - in practice for us each project can have it's own Dangerfile for unique to that project culture, and then anything that fits amongst all projects can get put in Peril (this repo is the Artsy peril config repo) where it defaults to all repos and we can handle specific edge cases for different repos in here.

I'm not quite sure I get what the question is, and whether this answers that though

[damassi]

Based on the outcome of the discussion, the RFC is implemented in a pull request, which is also open for discussion.

@orta and I were talking about this last week, and he had the idea of implementing a resolution template. We should append it to the discussion so that its clear what the outcome is as well as next steps.

As a bullet point I would also like to add some kind of formalized voting mechanism; 👍 or 👎 at the top, similar to how we did it in the Prettier RFC, with the option to abstain symbolized by some kind of :whatever: emoji.

[izakp]

@orta thanks! that answers my question - was not clear on the Danger / Peril relationship

[orta]

Alright, I'm closing this - I've clarified the RFC process in artsy/guides#4 and this generally seemed to be resolved.