[Pulp-dev] Roadmap Challenges

[Milan Kovacik]

Brian,

thanks for the proposal!
I've been considering a similar one for some time.

On Thu, Mar 29, 2018 at 9:13 PM, Brian Bouterse <bbouters at redhat.com> wrote:
> I want to start a discussion around how Pulp does roadmap planning and some
> of our current challenges. This is the pre-discussion part of a future PUP.
> I want to collaborate on characterizing the problems first before we discuss
> solutions.
>
> # The surface problem statement
>
> It very difficult for external stakeholders to answer some simple questions
> about any given feature:
>
> * How would a user use this feature exactly?
> * Is it completed? If not, how much is left to do?
> * Which release is this going in?
> * Has this feature been fully planned and accepted as a committed to piece
> of work?
>
> # deeper problems
>
> I believe there are two deeper problems contributing to the problem above.
>
> 1. Any given feature is typically spread across multiple Redmine tickets.
> There may be the first implementation, followup changes, adjustments,
> bugfixes, reworks, docs followups, etc. This makes it practically hard to
> have the information necessary to answer the first 3 questions ^.
>
> 2. Devs of core or a plugin have no clear way to clearly signal that a
> feature has been fully planned and is committed to. The 'sprint' field has
> been used heretofore, but the recent feedback suggests that mechanism may
> not be the best way to indicate that work has been fully planned and
> accepted. We need a clear way to answer the last question ^.
>
> Do you agree or disagree with these problem statements? Do you have anything
> to add about the problem statements?
>

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.


> Thanks!
> Brian
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>

Cheers,
milan