Discussion: improve RFC process about peril-settings HOT 8 CLOSED

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.

from peril-settings.

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.

from peril-settings.

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 😄 )

from peril-settings.

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.

from peril-settings.

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.

from peril-settings.

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

from peril-settings.

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

from peril-settings.

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

from peril-settings.