Le mardi 18 avril 2017 à 10:25 +0200, Niels de Vos a écrit : > On Mon, Apr 17, 2017 at 04:53:55PM -0700, Amye Scavarda wrote: > > On Fri, Apr 14, 2017 at 2:40 AM, Michael Scherer <mscherer@xxxxxxxxxx> > > wrote: > > > > > Le jeudi 13 avril 2017 à 18:01 -0700, Amye Scavarda a écrit : > > > > In light of community conversations, I've put some revisions on the > > > > Maintainers changes, outlined in the hackmd pad: > > > > https://hackmd.io/s/SkwiZd4qe > > > > > > > > Feedback welcomed! > > > > > > > > Note that the goals of this are to expand out our reach as a project > > > > (Gluster.org) and make it easy to define who's a maintainer for what > > > > feature. > > > > I'll highlight the goals in the document here: > > > > > > > > * Refine how we declare component owners in Gluster > > > > * Create a deeper sense of ownership throughout the open source project > > > > * Welcome more contibutors at a project impacting level > > > > > > > > We've clarified what the levels of 'owners' and 'peers' are in terms of > > > > responsibility, and we'll look to implement this in the 3.12 cycle. > > > > Thanks! > > > > > > So, I realize that the concept of component is not defined in the > > > document. I assume everybody have a shared understanding about what it > > > is, but maybe not, so wouldn't it make sense to define it more clearly ? > > > > > > Is this planned to be done later as part of "We will be working on > > > carving out new components for things that make logical sense." ? > > > > > > As for example, with regard to my previous comment, would > > > "infrastructure" be a component, would "documentation" be a component ? > > > > > > My understanding is that there's a working spreadsheet being refined to > > sort out what's an area that needs a maintainer defined, and what's > > something that maybe doesn't need a named maintainer. Documentation is a > > tricky place to get to, because that's something that you do just naturally > > so that future-you doesn't hate current-you. > > I agree that documentation should be part of the standard development > workflow. Unfortunately, this is not something that gets done without > reminding everyone about it. We still need maintainers/owners to bug > developers for documentation of new features, monitor the pull-request > queue and decide if the documentation is written in an acceptible way. There is also the overall issue iof documentation consistency. For example, style, glossary, etc, all kind of stuff that shouldn't be per component but aligned overall. > The maintenance of the gluster.readthedocs.io site might be a > infrastructure task? Wouldn't it be more logical to have it managed by the people that did champion RTD ? I am unable to find the discussions about it, but I am quite sure I had some concerns regarding RTD and wouldn't volunteer to maintain something where I had objections (such as "being unable to fix anything" is quite high on my usual objection list for taking responsibility of a piece of infra) -- Michael Scherer Sysadmin, Community Infrastructure and Platform, OSAS
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
