[Pulp-dev] RFC process
bbouters at redhat.com
Mon Feb 13 19:45:21 UTC 2017
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 . 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!
All the best,
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?
> 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
>> 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>
>>> 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:
>>> 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.
>>> 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.
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev