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

Tue Jun 23 14:35:51 UTC 2015

----- Original Message -----
> From: "Vijay Bellur" <vbellur at redhat.com>
> To: maintainers at gluster.org
> Sent: Tuesday, June 23, 2015 9:43:11 AM
> Subject: Re: [Gluster-Maintainers] Community Transparency [Was: Responsibilities and expectations of our maintainers]
> 
> Hey All,
> 
> I know that all of us are quite occupied at this point in time. I would
> love to have some responses on this one. Will appreciate greatly if you
> can spare some time off your schedule and chime in with your inputs.
> 
> Thanks,
> Vijay
> 
> On Friday 19 June 2015 06:30 AM, Vijay Bellur wrote:
> > Re-kindling the discussion again on this list.
> >
> > I agree with everything that Niels mentions here as expectations. In
> > addition I would like us to start thinking about building more
> > transparency in the community on how we operate as maintainers and also
> > lead by example so that it is very evident to the broader community
> > about we being serious about walking the talk.
> >
> > I would like us to think about a small list so that it can be
> > accomplished sooner than later. My top 3 for this list would be:
> >
> > 1. Some of the goals for maintainers are measurable: reviews completed,
> > reviews outstanding, attendance in IRC meetings, bugzilla backlog,
> > patches sent etc. We can send a report at some frequency
> > (bi-weekly/monthly) about these aspects so that the community observes
> > the quantitative aspects of our involvement.

Can some of these items be automated?

> >
> > 2. Sending a report at some frequency (weekly/bi-weekly) about
> > non-measurable aspects like happenings in our components, what we intend
> > doing in the near to mid term etc. This could also be a good way to get
> > more contributors to work on the immense backlog that all of us have and
> > also help explain to the broader community about why we are doing
> > something.

A template describing the report contents would be useful. If a single person 
could take on the responsibility of reminding us to create these reports, and 
ensure they are sent and edited properly, that would also be good. This would 
be a "maintainer liaison" to the community.

Joseph is in contact with a group of engineers at universities who may be 
interested in taking on gluster work, with a likely arrangement for them
to receive college credit, if anyone is interested in this.

> >
> > 3. Up the overall quality in a way that the community perceives it. I am
> > intending to declare that all of our components need to be "distaf
> > ready" over the next 3-6 months so that we have adequate coverage for
> > all our components.
> >
> > Thoughts, ideas and feedback welcome as ever :).
> >
> >
> > -Vijay
> >
> >
> > -------- Forwarded Message --------
> > Subject: [Gluster-devel] Responsibilities and expectations of our
> > maintainers
> > Date: Wed, 25 Mar 2015 14:04:10 +0100
> > From: Niels de Vos <ndevos at redhat.com>
> > To: gluster-devel at gluster.org
> >
> > Hi all,
> >
> > With many new features getting merged for glusterfs-3.7, I would like to
> > get your attention to some of the more 'boring' bits that come with
> > proposing and implementing a feature.
> >
> >
> > 1. Who is going to maintain the new features?
> >
> >      Features that are pretty self-contained, like adding a new xlator,
> >      daemon or the like, should get added to our MAINTAINERS file. Only
> >      very few features have provided patches for this, the others would
> >      need to still do so, or we can collect a bunch of them and add them
> >      all at once (might be easier to prevent conflicts).
> >
> >      Some features only add some functionality to existing components. If
> >      the current component maintainer asks your support for maintaining
> >      your added changes, please be very responsive.
> >
> >
> > 2. Maintainers should be active in responding to users
> >
> >      As a maintainer of a component, you (or the group of maintainers)
> >      have the (end) responsibility to respond to questions and problems
> >      reported by users. This does not mean that you are required to
> >      respond to all questions and problems yourself, but try to track
> >      responses by others and answer outstanding questions.
> >
> >      There are several ways our community users can ask questions and
> >      report problems:
> >        - gluster-users at gluster.org, gluster-devel at gluster.org lists
> >        - #gluster and #gluster-dev on Freenode IRC
> >        - https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS
> >
> >      Maintainers are expected to keep an eye on relevant topics,
> >      questions and bugs through these channels.
> >
> >
> > 3. What about reported bugs, there is the Bug Triaging in place?
> >
> >      Indeed, at the moment we have a weekly Community Bug Triage meeting.
> >      This meeting is intended as a fall-back for bugs that have not been
> >      triaged by community members (users, developers, managers, ...). It
> >      seems that most new bugs get triaged during the meeting, but this is
> >      an activity that can happen completely independently from the
> >      meeting. Maintainers and developers are strongly encouraged to
> >      triage bugs that are reported against the components that they work
> >      on. The following links contains the workflow for triaging, and
> >      bugzilla queries that show the untriaged bugs:
> >       - http://www.gluster.org/community/documentation/index.php/Bug_triage
> >       - https://public.pad.fsfe.org/p/gluster-bug-triage
> >       -
> > http://www.gluster.org/pipermail/gluster-devel/2015-March/044114.html
> >
> >      Reminder: anyone is welcome to join the Bug Triage meeting.
> >
> >
> > 4. Maintainers should keep an eye on open bugs affecting their component
> >
> >      When a bug has been triaged, someone would need to work on getting
> >      the problem fixed. Bugs move their status like this:
> >
> >          NEW -> NEW+Triaged -> ASSIGNED -> POST -> MODIFIED -> ...
> >
> >      What happens after MODIFIED is for the release maintainers and QA
> >      (also community) teams. Maintainers would mostly focus on the first
> >      steps of the process. To assist with this, I have created a Bugzilla
> >      report where you can click on the component, or the component/status
> >      and get a list of all bugs (without FutureFeature keyword):
> >       - http://red.ht/1BKWsRq
> >
> >      There is still an ongoing action item to find someone that has a
> >      good overview of how busy developers (mostly Red Hat) are and which
> >      community reported bugs should get fixed with priority. Maintainers
> >      are not expected to be managers that can force other developers to
> >      work on certain issues, but in most cases a friendly request does
> >      the trick too ;-)
> >
> >
> > 5. Maintainers are expected to be responsive on patch reviews
> >
> >      When a developer posts a patch to Gerrit, they are eager to hear
> >      about any changes they would need to make. Responding fast with a
> >      review also helps in getting the posted change updated quicker.
> >      Developers tend to switch between many tasks and having the change
> >      fresh in their memory helps with their responsiveness too. Our
> >      Guidelines for Maintainers list a few ways on how to receive email
> >      notifications and displaying a list of changes in Gerrit:
> >       -
> > http://www.gluster.org/community/documentation/index.php/Guidelines_For_Maintainers
> >
> >
> >
> > 6. Maintainers should try to attend IRC meetings
> >
> >      There is the weekly Gluster Community meeting on IRC. This is
> >      scheduled for every Wednesday. Maintainers and active developers are
> >      expected to attend these meetings whenever they can. More
> >      information about these meetings can be found here:
> >       - https://public.pad.fsfe.org/p/gluster-community-meetings
> >
> >
> > Note that these are mostly the expectations I have of maintainers, and I
> > try hard to fulfill them myself too. Let me know if you have any
> > questions, objections, additions or ideas about this topic. When you
> > reply, do so by inlining or bottom-posting your comments and feel free
> > to trim unrelated parts of this email in your response.
> >
> > Thanks,
> > Niels
> >
> >
> >
> 
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> http://www.gluster.org/mailman/listinfo/maintainers
> 