[Pulp-dev] RFC process

Fri Feb 24 22:34:15 UTC 2017

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 <erezende at redhat.com>
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 <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/20170224/e2e2e4c0/attachment.htm>