<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>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.<br></div><div><br></div><div># Going Well-ish</div><div><br></div><div>Overall, the Red Hat devs value <a href="http://pulp.plan.io">pulp.plan.io</a> being the authoritative record of technical discussions and decisions. There is value in all non-trivial work having an issue/feature/item filed in <a href="http://pulp.plan.io">pulp.plan.io</a>. For example, the QE team, build team, and various user and developer groups look at <a href="http://pulp.plan.io">pulp.plan.io</a> 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.</div><div><br></div><div># Opportunities (recalling ideas from the convo)<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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].</div><div><br></div><div>4. Understanding the 'why' later is important. Generally having a clear "Problem" and "Solution" section for every story and refactor would be good.<br></div><div><br></div><div># Questions</div><div><br></div><div>What specific changes would you suggest to have the planning process better serve your needs?</div><div><br></div><div>How can we help ensure the right people have visibility into planned, in-progress, and completed changes at the right time?</div><div><br></div><div>Is there some way we can better serve contributors who do not work for Red Hat?</div><div><br></div><div>How do we reach agreement as a community that a proposed solution is acceptable versus waiting for more proposals?</div><div><br></div><div>Are we benefiting from the "grooming" process?</div><div><br></div><div>Are we we benefiting from the "sprint planning" process?<br></div><div><br></div><div><br></div><div>[0]: <a href="https://www.youtube.com/watch?v=lF-bjxB2Nrk">https://www.youtube.com/watch?v=lF-bjxB2Nrk</a></div><div><br></div><div>Thank you to everyone who participated.<br></div></div><div dir="ltr"><br></div><div>All the best,</div><div>Brian</div><div><br></div></div></div>