I have an open design in the RFC repo that contains screenshots and feedback that I still plan to implement. I've kept it open due to some refactoring that has to happen before it can be implemented.
I like having a central place that I can design out a feature with other developers and UX team. Its nice to be able to refer back to it months later without having to hunt down a thread and scroll through it. It also makes linking to screenshots and comments much easier. I'm also open to other suggestions besides the mailing list, but my vote is to keep the RFC repo John Mitsch Red Hat Engineering (860)-967-7285 irc: jomitsch On Wed, Mar 15, 2017 at 8:07 AM, Eric D Helms <ericdhe...@gmail.com> wrote: > I also like the RFC repository. I have not merged or closed a lot of my > RFCs because I consider the designs to still be open discussions that need > re-visting and continued visibility. The ability to comment on specific > issues and have multiple threads going makes it much easier to follow than > a mailing list email IMO. > > On Wed, Mar 15, 2017 at 7:57 AM, Justin Sherrill <jsher...@redhat.com> > wrote: > >> >> >> On 03/13/2017 07:10 AM, Tomas Strachota wrote: >> >>> For me the biggest advantage of RFC repo over design discussions on >>> mailing list is that when you come back to it later, you immediately >>> see the latest state of the proposal without any need for reading >>> through the whole email thread. At the same time, when you what to see >>> the whole discussion you can display the outdated comments and older >>> commits. Sending/receiving comments in form of code reviews is quite >>> natural for me, but that's matter of personal preference. >>> >>> In my opinion both described issues (RFCs not being closed and design >>> decisions without RFCs) aren't connected with github reviews but with >>> the process around. Moving back to mailing lists won't help us with >>> that. Therefore I'd keep RFC repo and rather work on defining how we >>> decide on accepting/rejecting RFCs and who's responsible for keeping >>> an eye on that. >>> >> I also like the RFC repo. As someone that opened an RFC but never >> 'closed' it, it was mostly due to time, but I still plan to revisit it in >> the future. I'm not sure that its a 'bad' thing to have open RFCs (although >> we could auto close them after some months of inactivity). Similarly on >> the mailing list you'd just end up with discussions that never go anywhere. >> >> I'd be interested in other proposals, but like Tomas said, I don't think >> moving to the mailing list would solve many of the issues. >> >> -Justin >> >> >> >> >>> T. >>> >>> On Sun, Mar 12, 2017 at 9:52 AM, Tomer Brisker <tbris...@redhat.com> >>> wrote: >>> >>>> Hello, >>>> >>>> About a year ago, we decided to try using a new system for discussing >>>> design >>>> decisions prior to making changes, by creating a repo for RFCs [1]. >>>> Part of >>>> the problem was that when discussing on the mailing list, discussions >>>> tended >>>> to die out without a resolution, and eventually whoever wrote the code >>>> made >>>> the decision (or not). >>>> Since then, there have been about 30 proposals made in the repository. >>>> 22 of >>>> them are still open, most with no activity for months. >>>> So I feel fairly safe to say that this change has not led to the wanted >>>> result of getting decisions made faster or with more discussion. A >>>> significant part of the proposals have less then 10 comments, in many >>>> cases >>>> all from just one or two respondents. Eventually proposals are still >>>> decided >>>> on only when someone goes ahead, writes the code and gets it merged. >>>> This has also led to some discussions taking place without all of the >>>> developers even knowing about them, as it would seem most don't follow >>>> that >>>> repo regularly, leading to repeated discussions when a PR is created. >>>> In addition, some design decisions are still being made without going >>>> through the RFC process, either by mailing list discussions or by people >>>> just creating PRs without any prior discussion. >>>> >>>> I'm not sure what we can do to increase peoples' involvement in these >>>> discussions, nor what would be a better way of making design decisions, >>>> but >>>> let's try to figure it out since this attempt has not worked out as >>>> expected >>>> in my opinion. >>>> >>>> [1] original discussion - >>>> https://groups.google.com/forum/#!msg/foreman-dev/P9uRYV5K1D >>>> c/xKMnzOOqDgAJ >>>> >>>> -- >>>> Have a nice day, >>>> Tomer Brisker >>>> Red Hat Engineering >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups >>>> "foreman-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an >>>> email to foreman-dev+unsubscr...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "foreman-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to foreman-dev+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Eric D. Helms > Red Hat Engineering > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
