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

2016-09-06 Thread Pranith Kumar Karampuri
On Wed, Sep 7, 2016 at 6:07 AM, Sankarshan Mukhopadhyay <
sankarshan.mukhopadh...@gmail.com> wrote:

> On Wed, Sep 7, 2016 at 5:10 AM, Pranith Kumar Karampuri
>  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
> 
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

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

2016-09-06 Thread Sankarshan Mukhopadhyay
On Wed, Sep 7, 2016 at 5:10 AM, Pranith Kumar Karampuri
 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.

> 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?

> 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

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel


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

2016-09-06 Thread Pranith Kumar Karampuri
hi,
 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.
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:
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
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel