[Pulp-dev] Roadmaps for plugins
rchan at redhat.com
Tue Oct 17 19:35:53 UTC 2017
Thanks for the feedback. Thank you for sending that example - it was very
I think we are struggling to figure out how granular to make things. I see
we can do a better job of communicating some of the priority and "if ever"
question on an issue. This was a good reminder that the folks working on a
plugin will want to go off of their initial thoughts and also query our
backlog to assess bugs and feature requests currently documented there as
part of the iterations.
On Mon, Oct 16, 2017 at 5:13 PM, Tom McKay <thomasmckay at redhat.com> wrote:
> This sounds interesting but as a community user my biggest complaint is
> not knowing 1) when an issue will be worked on, and 2) how to influence the
> As an example, take the story 2602: 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?
> An example of a roadmap that I've found useful is openshift's. 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.
> Looking forward to hearing more!
>  To be fair, a dev on foreman/Sat-6 with a vested interest in container
>  https://pulp.plan.io/issues/2602
>  https://ci.openshift.redhat.com/roadmap_overview.html
> On Mon, Oct 16, 2017 at 4:17 PM, Robin Chan <rchan at redhat.com> wrote:
>> 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
>> *Why? - What will a roadmap help do?*
>> Communicate relative priority of work for a plugin
>> Determine MVP (for Pulp 3) for a plugin
>> Help identify dependencies on work outside of the plugin
>> Capture architectural decisions especially when departing from past Pulp
>> 2 implementations (was this implied in conversation? writing this out is
>> Provide direction with the understanding that work planned farther in
>> future is subject to change.
>> EPIC level descriptions of work - so not user stories, not tasks, not use
>> Describe major functionality delivered in an order
>> Use y release descriptions for EPICs
>> 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
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev