Closed juliandescottes closed 7 years ago
gregtatum
commented
7 years ago From the email:
This feature is not tested or maintained. The only documentation is a mention at http://docs.firefox-dev.tools/frontend/react-tips.html On the latest mozilla-central enabling it can easily break the debugger & netmonitor.
I never used it, and would say remove it. Anything that is not tested and doesn't have a maintainer sounds really scary.
juliandescottes
commented
7 years ago I'm great at making confusing issues :) @gregtatum I think your comment should go to #18
This issue is to discuss how we want to handle small RFCs such as #18
Options I can think about:
Using this repo to discuss all our proposals could be nice. This way we have a central place for discussions about what is changing in DevTools. On the other hand I admit that when I created the PR for this small change, it felt wrong. So I'd like to get opinions from the rest of the team here.
jasonLaster
commented
7 years ago either a PR or issue is fine.
I'd tentatively suggest PRs for new experiments. Issues for other things
In the end everything is an issue in the GH scheme
juliandescottes
commented
7 years ago I think I agree with that proposal. The nice thing about PRs if that they have a flow where they are either accepted or not, while a closed issue doesn't really tell you what the decision was.
Which means that for changes that are discussed via issues, one has to read the issue to understand if it was accepted or not. But we can leave a clear last comment with a huge OK/KO picture :)
Furthermore, I think merging .md files for every change that needs to be discussed would end up polluting this repo. Only significant refactors and changes should deserve to have an .md file.
jasonLaster
commented
7 years ago :+1:
It strikes me that this is a good testcase. I would prefer this proposal as an issue too :P
sole
commented
7 years ago What about... a) open the issue explaining your proposal b) discussion happens c) agreement is reached d) a new RFC document is created, summarising the proposal and the action taken, for future reference
done!
Maybe we need to simplify the RFC process too?
juliandescottes
commented
7 years ago That sounds good to me. I'll submit a PR to modify the readme for the repository along those lines. And we can mention it during the next DevTools meeting. Maybe we can have a dedicated issue "label" for proposals.
d) a new RFC document is created, summarising the proposal and the action taken, for future reference
So you think we should have RFC documents for all proposals?
captainbrosset
commented
7 years ago Looking forward to discussing this in today's meeting. I'm all for simplifying the process. It was created 7 months ago, and never used. It's a clear sign that it's not solving a need.
I think the main reasons are:
I think we need a first successful test case for this to work. This will require us to actively be on the look out for the next decision-making opportunity, and bring the discussion here.
In any case, I agree that it needs simplifications. What @sole said before sounds good to me. Instead of sending an email, let's just open an issue for people to discuss and agree on something. When an agreement is reached, we can tag the issue with a "solved" tag, add a big happy emoji or something as a last comment, lock the discussion and close the issue. This way, it's easy to look for closed issues with the "solved" tag to list all past decisions.
Not sure about creating a document out of this however. The details are going to be in the issue anyway. Maybe it would help make it clear if issues are very long and verbose?
juliandescottes
commented
7 years ago Thanks @captainbrosset , the previous comment captures my opinion as well.
I initially just wanted to reinforce the "create an issue to gather feedback" part and created a branch at https://github.com/juliandescottes/rfcs/tree/readme . But I think we need to be more extreme and completely remove the process described in the current readme. New process:
To close issues, we can still go through a minimal PR, which will simply be a short text file summarising the decision and linking back to the issue.
Even after the simplification, this repository should only be kept if we consider this solution more valuable than status-quo
Pros for GH issues in my opinion:
Cons:
Emails are great for notifying, so we should not stop using the mailing list. Announce on the mailing list, then discuss in the issue. (@sole offered to look for a way to send an email automatically if we decide to keep this repo :))
As Patrick said, we are also very rarely requesting feedback from the rest of the team, except during team meetings. It's true we don't often have team wide decisions to make. But we could also request feedback for tool-specific decisions. Maybe having a good async discussion tool can help there.
If by the end of Q3 it is in the same shape as it is now, let's kill it.
juliandescottes
commented
7 years ago Merged PR #20 , closing!
See #18
I initially started discussing this on the dev-developertools mailing list https://groups.google.com/forum/#!topic/mozilla.dev.developer-tools/HGpjIQuRJGg
@sole mentioned we could use the RFC process for this and I agreed based on the assumption that it would be easier to share the discussion and to keep track of the motivations. However for such a trivial change, it doesn't really fit the template (and the md I submitted ignores many of the suggested items from the template)
My main goal is to gather feedback and get a go/no-go. Maybe this is a bad fit for a RFC or maybe we need a simpler flow/template for smaller changes?
Thoughts?