<div dir="ltr"><div>This sounds interesting but as a community user[1] my biggest complaint is not knowing 1) when an issue will be worked on, and 2) how to influence the priority.</div><div><br></div><div>As an example, take the story 2602[2]: As a user, I want docker repos to have "mirror on sync". It's difficult for me, not being in all the meetings and plannings, to know if this issue will ever be addressed. Will a roadmap be tied to specific issues for the plugins? Will there be a way for casual consumers of the plugin to influence priority?</div><div><br></div><div>An example of a roadmap that I've found useful is openshift's[3]. It doesn't necessarily help me with all the issues, or if an issue will ever be worked on, but is a nice quick overview.</div><div><br></div><div>Looking forward to hearing more!</div><div><br></div><div><br></div>[1] To be fair, a dev on foreman/Sat-6 with a vested interest in container images<br>[2] <a href="https://pulp.plan.io/issues/2602">https://pulp.plan.io/issues/2602</a><br>[3] <a href="https://ci.openshift.redhat.com/roadmap_overview.html">https://ci.openshift.redhat.com/roadmap_overview.html</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 16, 2017 at 4:17 PM, Robin Chan <span dir="ltr"><<a href="mailto:rchan@redhat.com" target="_blank">rchan@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div>Hello,<br><br>During our internal Pulp meeting this year, we discussed creating a roadmap for plugins.  I would like to capture our discussion and ask for feedback so that we can start working on our first few roadmaps for plugins.  We hope that this will be an iterative approach to planning and creating roadmaps, extending it to other plugins or core if they are helpful.<br><br><u>Why? - What will a roadmap help do?</u><br></div>Communicate relative priority of work for a plugin<br></div>Determine MVP (for Pulp 3) for a plugin<br></div>Help identify dependencies on work outside of the plugin</div><div>Capture architectural decisions especially when departing from past Pulp 2 implementations (was this implied in conversation? writing this out is good.)</div><div>Provide direction with the understanding that work planned farther in future is subject to change.<br></div><div><br></div><u>What<br></u></div>EPIC level descriptions of work - so not user stories, not tasks, not use cases.<br>Describe major functionality delivered in an order<br></div>Use y release descriptions for EPICs<br><br></div>What did I forget to add?  What else would be helpful to add to a roadmap, take away, or state that it would be described/accounted for elsewhere?<br><br></div>Thanks,<br></div>Robin<br><div><div><div><div><div><u></u><div><br></div></div></div></div></div></div></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>