[Pulp-dev] Improving our planning processes?

[Brian Bouterse]

Today the Red Hat Pulp devs had a process retrospective on the Pulp
feature/refactor planning process. I'd like to share some of my takeaways
and also ask a few related questions to promote discussion. Please correct
any misunderstandings in this note from our discussion.

# Going Well-ish

Overall, the Red Hat devs value pulp.plan.io being the authoritative record
of technical discussions and decisions. There is value in all non-trivial
work having an issue/feature/item filed in pulp.plan.io. For example, the
QE team, build team, and various user and developer groups look at
pulp.plan.io to understand what is going on and the status of various
efforts in ways the source tree across multiple repos can't tell you
easily. We had some differing opinion on what qualifies as non-trivial but
not huge differences.

# Opportunities (recalling ideas from the convo)

1. Filing issues/stories earlier. In some cases issues get filed after much
thought has already gone into figuring out a solution. (I've done this
several times for example). These cases miss the opportunity to solicit
more ideas more quickly on the problem. Filing a problem statement without
any solution now is probably better than a problem and a solution later.

2. Recapping the final problem and solution on the description at the top
as it changed during discussion is desirable. Having issues with an
incorrect top description and the actual solution as comment 37 makes
discussing a complex topic over time even more complex.

3. Advertising the state of work to solicit more input. We know the mailing
list is probably the right way to draw attention to feature discussions,
but I'm not sure exactly when and how. Ideas would be helpful here. There
is related to a 2018 talk on asynchronous decision making (I think) [0].

4. Understanding the 'why' later is important. Generally having a clear
"Problem" and "Solution" section for every story and refactor would be good.

# Questions

What specific changes would you suggest to have the planning process better
serve your needs?

How can we help ensure the right people have visibility into planned,
in-progress, and completed changes at the right time?

Is there some way we can better serve contributors who do not work for Red
Hat?

How do we reach agreement as a community that a proposed solution is
acceptable versus waiting for more proposals?

Are we benefiting from the "grooming" process?

Are we we benefiting from the "sprint planning" process?


[0]: https://www.youtube.com/watch?v=lF-bjxB2Nrk

Thank you to everyone who participated.

All the best,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20190122/59c2ee20/attachment.htm>