[Gluster-Maintainers] Community Transparency [Was: Responsibilities and expectations of our maintainers]

[Rajesh Joseph]

> > ----- Original Message -----
> > > On Wed, Jun 24, 2015 at 12:39:39AM -0400, Krishnan Parthasarathi wrote:
> > > > 
> > > > > Currently, we need more attention to the way of working, in and with,
> > > > > the community and see how to increase the outreach of all the work we
> > > > > are doing, else we may induce estrangement in this space.
> > > > > 
> > > > 
> > > > Yes. We could improve our engagement during design proposals.
> > > > Oftentimes,
> > > > there
> > > > is an announcement style mail and then the commit.
> > > 
> > > More often than not, I do not see an announcement style email. We only
> > > seem to do that for bigger changes, not smaller ones or things that are
> > > contained to only one component.
> > 
> > As long as we recognise that it has happened for big changes and is
> > unhealthy
> > is good. Lack of discussion for big changes makes maintaining them
> > difficult.
> > A streamlined merge-window based approach would help in scheduling big
> > changes,
> > giving time for more discussion. Thoughts?
> 
> I think a "merge window" mainly helps the top most maintainers, like
> Linus for the Linux kernel. He normally gets merge requests sent by
> sub-tree maintainers. Those sub-tree maintainers (who also have other
> sub-tree maintainers) often accept patches outside of the merge window
> too. There is a certain expectation of Linus merging all requests from
> other maintainers during the "merge window".
> 
> In the case for our maintainers, we do not get "ready to merge" patches.
> We still need to review them. A "review window" sounds more suitable for
> how we work, and it sets the right expectations for developers posting
> patches.
> 
> Consider something like this:
>  - a monthly schedule, starting the 1st of each month
>  - 3 weeks of "post anything"
>  - last week+ for "review window"
> 

I think when features are accepted into a release the feature owner should
clearly provide important milestones. Update feature page with overall design
which need not be very detail, but should give sufficient information to others
(especially maintainers) on what the proposed changes are and how it will
impact other components. This way maintainers will be aware when patches for
a feature will land for review and he/she will not be caught off guard with huge
patches for review near the end of release cycle.

And as suggested by Niels and others if keep community engaged in our progress
then their will be fewer surprises at review time.

I also like to suggest one more thing. Each feature or component has its own priorities.
But we should also look into the release priority. E.g. in this release lot of features
got committed into the branch, but we all neglected the logging patch. As far as I think
logging feature should have been completed long back. Shyam had sent the details about the
feature long time back in gluster devel and the interns have done an excellent
job in sending those patches and gone through numerous cycle of rebasing. We all got busy
in our own features and neglected logging.

My opinion is that if want to be a great community we should make writing, understanding
and maintaining code as easy as possible for others. Recently glusterd has 
taken some good initiative in improving the code maintenance. Also there are some good
initiative in improvements in general gluster documentation. We should have more such initiatives.
But more important as an acceptance criteria we should set clear expectations. Near the end
of release cycle we forget about code readability, in-source documentation and maintainability
aspect of the code. Which normally treated as a "good-to-have" feature.

It's not healthy if only few handpicked people know about the feature. As a feature owner/maintainer
we should see that its easy for adoption.

These all are my personal views and if you disagree I like to understand your point of view.

Best Regards,
Rajesh