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

Tue Jun 23 15:09:08 UTC 2015

<some comments inline below>

Reading (and re-reading) the mail thread, I wanted to add to this *list* 
of practices some further observations, and hence top posting the same.

I would like maintainers (and possibly others working on Gluster) to ask 
themselves the following question:
   - "What would I need/do if I was in a remote island with just a 
network connection and a maintainer for some areas of Gluster?" (well, I 
assume you travel to a remote island with your laptop and solar charger)

I say the above, as I am physically and time zones away from a large 
group of maintainers, and there are many times, when I cannot fathom 
what drives priorities or why some things are noticed, or acted upon, 
and some not.

If I ask myself the above and see how I need to engage with the 
community and other maintainers, the list of things Niels brings out 
becomes self evident, but also the fact that we need to make efforts 
done around these elements more public (responses to mails, updates to 
BZs are already public, but your thoughts are not).

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.

Shyam

On 06/19/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.

Agree, for a more positive spin than looking like monitoring of 
maintainers here, I would suggest we keep this as more a backlog of 
activities. What I mean is, reviews completed vs outstanding, is more an 
indicator of action to take, which is like a feedback loop for the 
maintainer. On the same note, BZ backlog helps.

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

I believe we need this done *for sure*, as otherwise cross components I 
am sometimes (more often than not) clueless on happenings.

Also, tracking longer term thoughts in such a *report* would help.

I would suggest we also have an overall Gluster report on the same 
lines, so that people have a common point where they can get to know 
regarding the happenings across Gluster, possibly component related 
happenings, can be a threaded response to the same on the lists.

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

Agree, this would certainly help towards improving the quality of 
Gluster (among other efforts). It would be good to list what the short 
comings are in terms of quality and how distaf would help addressing the 
same, or if we need a broader goal and see how to achieve this better or 
what more could be pending.

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