[Gluster-devel] Post mortem of features that didn't make it to 3.9.0

[Pranith Kumar Karampuri]

On Wed, Sep 7, 2016 at 6:07 AM, Sankarshan Mukhopadhyay <
sankarshan.mukhopadhyay at gmail.com> wrote:

> On Wed, Sep 7, 2016 at 5:10 AM, Pranith Kumar Karampuri
> <pkarampu at redhat.com> wrote:
>
> >      Do you think it makes sense to do post-mortem of features that
> didn't
> > make it to 3.9.0? We have some features that missed deadlines twice as
> well,
> > i.e. planned for 3.8.0 and didn't make it and planned for 3.9.0 and
> didn't
> > make it. So may be we are adding features to roadmap without thinking
> things
> > through? Basically it leads to frustration in the community who are
> waiting
> > for these components and they keep moving to next releases.
>
> Doing a post-mortem to understand the pieces which went well (so that
> we can continue doing them); which didn't go well (so that we can
> learn from those) and which were impediments (so that we can address
> the topics and remove them) is an useful exercise.
>

Ah, that makes more sense. We should also do these for features that went
well as well.


>
> >     Please let me know your thoughts. Goal is to get better at planning
> and
> > deliver the features as planned as much as possible. Native subdirectoy
> > mounts is in same situation which I was supposed to deliver.
> >
> > I have the following questions we need to ask ourselves the following
> > questions IMO:
>
> Incident based post-mortems require a timeline. However, while the
> need for that might be unnecessary here, the questions are perhaps too
> specific. Also, it would be good to set up the expectation from the
> exercise - what would all the inputs lead to?
>

Timeline is a good idea. But I am not sure what would be a good time. I
think it is better to concentrate on getting the 3.9.0 release out, so may
be in the last week of this month, we can start this exercise in full flow.
At the moment we want to collect this information so that we acknowledge
the good things we did for the release and things we need to avoid in the
future releases. Like I was mentioning, the main goal at least in my mind
was to prevent these slips as much as possible in future. At the moment the
roadmap is more like a backlog, at least that is how it seems like IMO, we
keep pushing them to next release based whether we get time or not. Instead
it should be like a proper roadmap where we are sure we will deliver them
for the release with good confidence.


>
> > 1) Did we have approved design before we committed the feature upstream
> for
> > 3.9?
> > 2) Did we allocate time for execution of this feature upstream?
> > 3) Was the execution derailed by any of the customer issues/important
> work
> > in your organizatoin?
> > 4) Did developers focus on something that is not of priority which could
> > have derailed the feature's delivery?
> > 5) Did others in the team suspect the developers are not focusing on
> things
> > that are of priority but didn't communicate?
> > 6) Were there any infra issues that delayed delivery of this
> > feature(regression failures etc)?
> > 7) Were there any big delays in reviews of patches?
> >
> > Do let us know if you think we should ask more questions here.
> >
> > --
> > Aravinda & Pranith
>
>
>
> --
> sankarshan mukhopadhyay
> <https://about.me/sankarshan.mukhopadhyay>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160907/c71e55bb/attachment.html>