[Pulp-dev] RFC process

Mon Feb 13 22:09:28 UTC 2017

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 <bbouters at redhat.com> 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 <daviddavis at redhat.com>
> 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 <ipanova at redhat.com> 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 <daviddavis at redhat.com>
>>> 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
>>>> Pulp-dev at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>

-- 
Elyézer Rezende
Senior Quality Engineer
irc: elyezer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170213/3b118a62/attachment.htm>