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

[Vijay Bellur]

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.

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.

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: Attached Message Part
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20150619/78aba7d9/attachment-0001.sig>
-------------- next part --------------
_______________________________________________
Gluster-devel mailing list
Gluster-devel at gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel