On Tue, Apr 3, 2018 at 3:47 PM, Austin Macdonald <aus...@redhat.com> wrote: > Interesting proposals Milan! > > I am forking Brian's email so that thread can focus on communication, > redmine, etc.
Thanks, I guess it would best go hand-in-hand with the process update proposal for the Technical specifications/blue-prints PUP: >> I'd add that many a time, an e-mail based technical discussion gets >> messy and unfolds in multiple branches over multiple months. >> I'd like to propose we adopt a Technical Specification concept, living >> in a separate GitHub repo, similar to the PUP process. >> This would take advantage of our review process, preferably requiring >> multiple (core) reviewers acks before merging, allowing Redmine to be >> used for planning/tracking the (design) work. >> I think it's easier to manage the life-cycle of a larger Technical >> Specification in a revision system document than an e-mail thread and >> a single Redmine issue. >> It also helps (feature) documentation and provides context. > > On Tue, Apr 3, 2018 at 8:13 AM, Milan Kovacik <mkova...@redhat.com> wrote: >> >> I'd also like to propose formal Project Technical Lead and a formal >> Project Community Lead roles to be able to decide in case of competing >> (technical) ideas or planning priorities. >> These would have to be time-boxed (half a year) and folks would elect >> the leader for a period based on leader's program, such as focus on >> particular goals for instance testing or refactoring. >> Any single person would be able to perform either the Community or the >> Technical Lead role in any given period but not both at the same time. >> The Community Lead role would take care for organizing the Technical >> Lead elections and vice versa, the Technical Lead would take care >> about organizing the Community Lead elections. >> The electorate would be the active contributors for both the roles. >> The candidates would be the active contributors too. >> >> This would open up the decision making process for anyone from the >> community, would encourage transparency, accountability and >> responsibility and would allow us to come to a decision on competing >> (technical) ideas or planning issues in case we'd got stuck. >> >> Cheers, >> milan >> >> On Mon, Apr 2, 2018 at 8:38 PM, Brian Bouterse <bbout...@redhat.com> >> wrote: >> > I agree the decision process for core itself needs discussion. For now, >> > I'm >> > only able to offer facilitating a convo that focuses on the >> > communication >> > aspects not the decision process. I would like to improve the >> > transparency >> > into the features that will and won't be in any given release for our >> > stakeholders. I hope we do discuss decision process as its own >> > discussion; >> > it's certainly deserving of a pup of its own. >> > >> > For the communication issues, soon I will share a basic outline of one >> > way >> > we could use Redmine for release planning. This would be a starter idea >> > towards a solution for us to modify together. >> > >> > >> > >> > On Mon, Apr 2, 2018 at 9:08 AM, Austin Macdonald <aus...@redhat.com> >> > wrote: >> >> >> >> I agree with the problems that Brian listed, but I hope we can focus on >> >> the decision making process itself in addition to how those decisions >> >> are >> >> communicated. >> > >> > >> > >> > _______________________________________________ >> > 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
