I pushed another version based on feedback. The changes came as a new commit so you can see them there. I have 2 areas that I want to discuss before merging.
== proposed change 1 == I want really want beautifully readable proposals on pulpproject.org. That being said, I think we should pull that out of this proposal and instead go with: * A dedicated repo with this proposal's text as a README at the root. This would effectively adopt @mhrivnak's comment here[0]. * We can figure out how to get those onto pulpproject.org as a separate effort == proposed change 2== Also I want to have the proposals live as a pull request until they are decided on. The current proposal has them being merged regularly. This would reduce friction by having proposals be created/revised without a single core dev needing to be involved. Also collaborators can push to each other's branches with github permissions so collaboration is still very possible. In fact @daviddavis did that with this meta PR. This part is basically written here [1] as a change. [0]: https://github.com/pulp/pulpproject.org/pull/50/#discussion_r103085714 [1]: https://github.com/pulp/pulpproject.org/pull/50/files#diff-65d93959a5eea99a63191c1a80e105b4R284 Comments and ideas are welcome either via e-mail or on the PR. Thanks! Brian On Fri, Feb 24, 2017 at 6:33 PM, Dennis Kliban <dkli...@redhat.com> wrote: > 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 <bbout...@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 <ereze...@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 <bbout...@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 <davidda...@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 <ipan...@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 <davidda...@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@redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pulp-dev mailing list >>>>> Pulp-dev@redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> Pulp-dev@redhat.com >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >>> >>> -- >>> Elyézer Rezende >>> Senior Quality Engineer >>> irc: elyezer >>> >> >> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev