The things that I like about this proposal: - The proposals are always merged so the community can reference them in the future even if the proposal is not adopted. I like learning from history. - Revisions to the proposal are additional commits stored in git. Having a record of changes can be valuable as the proposal lives on and evolves. - All the proposals are available on pulpproject.org or some other wesbsite for anyone to see - including search engines.
I am not too thrilled about the discussion living separate from the proposal, but I am a fan of our mailing lists. I would be happy with this proposal being merged as is so we can announce it for voting and/or further discussion on pulp-dev list. -Dennis On Fri, Feb 24, 2017 at 5:34 PM, Brian Bouterse <[email protected]> wrote: > I pushed a new version based on feedback on the PR. It outlines several > alternatives that we should consider along with downsides. > > What about leaving it as a pull request for longer? > <https://github.com/pulp/pulpproject.org/pull/50/files#diff-65d93959a5eea99a63191c1a80e105b4R277> > What about using Github for discussion? > <https://github.com/pulp/pulpproject.org/pull/50/files#diff-65d93959a5eea99a63191c1a80e105b4R292> > We could store the PEPs in Redmine. Why aren't we using Redmine? > <https://github.com/pulp/pulpproject.org/pull/50/files#diff-65d93959a5eea99a63191c1a80e105b4R262> > > There are also Downsides > <https://github.com/pulp/pulpproject.org/pull/50/files#diff-65d93959a5eea99a63191c1a80e105b4R250> > of this proposal. > > My opinion is a +1 to leaving it as a pull request for longer to allow > more autonomy for creation and revision of proposals. Also, we can > additionally use Github for feedback, but that email threaded discussion > should also be allowed to include a broader input from users who don't live > in Github like most of us do. Both of these not-yet-done simple rewrites > would remove these from the list of alternatives and incorporate them into > the proposal itself. I'm happy to make such changes with input from others. > > Also in the Unresolved Questions > <https://github.com/pulp/pulpproject.org/pull/50/files#diff-65d93959a5eea99a63191c1a80e105b4R309> > section having an acronym or initialization of a name for these would be > nice. > > It would be great to get feedback by 00:00 UTC on Tuesday the 28th (that's > 7pm on Feb 28th). I'll try to be more responsive with the edits also. > > Thanks for the input so far. > > -Brian > > On Mon, Feb 13, 2017 at 5:09 PM, Elyezer Rezende <[email protected]> > wrote: > >> I would like to comment about the C4 [1] which is "the Collective Code >> Construction Contract (C4), [...], aimed at providing an optimal >> collaboration model for free software projects". >> >> It does not mention about creating RFCs specifically but provides some >> guidelines that may help when implementing them. >> >> [1] https://rfc.zeromq.org/spec:42/C4/ >> >> On Mon, Feb 13, 2017 at 5:45 PM, Brian Bouterse <[email protected]> >> wrote: >> >>> I want to share some ideas on a possible proposal process. It's inspired >>> by processes in the Foreman, Python, and Django communities along with >>> several discussions I've had with core and community users. This is written >>> as a concrete proposal, but it is 100% changeable. >>> >>> I'm doing the meta thing and using the process I'm proposing to propose >>> the process. The proposal is here [0]. It's unmerged (not the process) >>> because I suspect we'll want a dedicated repo. This proposal, if adopted, >>> is still a living document (like Python PEP 0001) so even if its approved >>> it would still be an evolving document. >>> >>> Feedback and collaboration is welcome! >>> >>> [0]: https://github.com/pulp/pulpproject.org/pull/50 >>> >>> All the best, >>> Brian >>> >>> On Fri, Feb 10, 2017 at 6:01 PM, David Davis <[email protected]> >>> wrote: >>> >>>> I also like the idea of using plan.io for our RFCs. The only thing >>>> that github or etherpad offers over plan.io is the ability to >>>> edit/update the RFC. If the RFC is in the body of the story/task in >>>> Redmine, then I think it can only be edited by admins. Maybe we can use the >>>> comments or not worry about editing the RFC though. >>>> >>>> There were also some other points brought up this past week about >>>> RFCs—mostly around workflows. One important thing I forgot to consider is >>>> how to accept RFCs. Should we vote on them? Or perhaps try to arrive at >>>> some sort of consensus? >>>> >>>> >>>> David >>>> >>>> On Mon, Feb 6, 2017 at 12:31 PM, Ina Panova <[email protected]> wrote: >>>> >>>>> I think all mentioned options could be used, but we need to have a >>>>> starting point. Something that would track a discussion for a long time. >>>>> And i lean towards ---> open a story/task (as a starting point). >>>>> Having a story/task opened we can always reference it in mail >>>>> discussion or etherpad. >>>>> Why i prefer to have all/most of the discussion happen on the >>>>> story/task? >>>>> Because i cannot guarantee that i will not miss somehow the email or >>>>> etherpad. I actually often find myself trying to dig through dozens of >>>>> mails to find the right one. Same with the etherpads :) >>>>> Because i receive notifications when someone adds a comment on the >>>>> task/story, even after one month or two. This does not happen with >>>>> etherpad, and i actually will not see the new comments/ideas until i will >>>>> check the pad by myself. >>>>> Periodically. From time to time. Remembering the right pad number, and >>>>> of course i do not remember it, so i will need to dig into my mails to >>>>> find >>>>> it out. >>>>> >>>>> >>>>> >>>>> -------- >>>>> Regards, >>>>> >>>>> Ina Panova >>>>> Software Engineer| Pulp| Red Hat Inc. >>>>> >>>>> "Do not go where the path may lead, >>>>> go instead where there is no path and leave a trail." >>>>> >>>>> On Mon, Feb 6, 2017 at 4:59 PM, David Davis <[email protected]> >>>>> wrote: >>>>> >>>>>> One of the things that came up in our retrospective is that we don’t >>>>>> have a formal way to propose changes to our codebase and processes (aka >>>>>> RFCs). This was motivated in part by the recent discussion on merging >>>>>> forward commits on our pulp-dev mailing list. >>>>>> >>>>>> I'd like to maybe discuss a way we can propose RFCs and then document >>>>>> this process in our docs. It sounds like there has already been some >>>>>> discussion about how to handle RFCs so I apologize coming into this >>>>>> without >>>>>> having any background. >>>>>> >>>>>> Thinking through RFCs, I see two things to address. First is the >>>>>> actual format of the RFC. I see some RFCs in plan.io but it doesn’t >>>>>> seem like there’s a standard way of formatting an RFC. Should there be? >>>>>> For >>>>>> reference, here's the template for foreman RFCs. I think it might serve >>>>>> as >>>>>> a good starting point: >>>>>> >>>>>> https://github.com/theforeman/rfcs/blob/master/0000-template.md >>>>>> >>>>>> Secondly, there’s the question of where to discuss and archive RFCs. >>>>>> Some possible options: >>>>>> >>>>>> 1. Open a story or task on plan.io >>>>>> 2. Use a GitHub repo to store and discuss RFCs (e.g. >>>>>> https://github.com/theforeman/rfcs) >>>>>> 3. Write the RFC on an Etherpad and once accepted, open a plan.io >>>>>> issue. >>>>>> 4. Just send out RFCs to the mailing list >>>>>> 5. Something else? >>>>>> >>>>>> I was thinking we could also use the mailing list in addition to >>>>>> options 1-3 by sending out an email pointing people to the actual RFC. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> David >>>>>> >>>>>> _______________________________________________ >>>>>> Pulp-dev mailing list >>>>>> [email protected] >>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> [email protected] >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> >> >> -- >> Elyézer Rezende >> Senior Quality Engineer >> irc: elyezer >> > > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
