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
