[Pulp-dev] Improving technical decision making

Milan Kovacik mkovacik at redhat.com
Tue Apr 3 16:02:47 UTC 2018

On Tue, Apr 3, 2018 at 3:47 PM, Austin Macdonald <austin at 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 <mkovacik at 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 <bbouters at 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 <austin at 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 at redhat.com
>> > https://www.redhat.com/mailman/listinfo/pulp-dev
>> >

More information about the Pulp-dev mailing list