[Pulp-dev] RFC process

Fri Feb 24 23:33:54 UTC 2017

The things that I like about this proposal:

- The proposals are always merged so the community can reference them in
the future even if the proposal is not adopted. I like learning from
history.
- Revisions to the proposal are additional commits stored in git. Having a
record of changes can be valuable as the proposal lives on and evolves.
- All the proposals are available on pulpproject.org or some other wesbsite
for anyone to see - including search engines.

I am not too thrilled about the discussion living separate from the
proposal, but I am a fan of our mailing lists. I would be happy with this
proposal being merged as is so we can announce it for voting and/or further
discussion on pulp-dev list.

-Dennis

On Fri, Feb 24, 2017 at 5:34 PM, Brian Bouterse <bbouters at redhat.com> wrote:

> 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
>>
>
>
> _______________________________________________
> 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/20170224/cf7d1442/attachment.htm>