[Pulp-dev] RFC process

[David Davis]

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170210/b073a6a9/attachment.htm>