Module Owners' List Action Plan
Mitchell Baker
Gerv is going to maintain an accurate module owner's list that is not
generated by "despot." He will do the maintenance on a wiki page (which
has control on who can write to it). There's a proposed method for
getting this data into www.m.o so to meet the desire that it look and
feel definitive -- see item 4 below.
Absent any new and serious objections, Gerv will start on items 1
through 4 below shortly. I'd like to hear from those folks who feel
strongly about definitiveness and www.m.o whether you feel item 5 is
important enough to warrant the effort.
More details.
1. We can't use despot for Mercurial without rewriting it. That
project is not currently underway.
2. We must have an up-to-date list of module owners. So for the
foreseeable future that list will be created / maintained some other way.
3. The options are creating this in the www.m.o source tree, using CVS
and perhaps the venerable - but not maintained - tool "Doctor," or (b)
maintaining this in wiki.mozilla org. with appropriate access control.
4. Gerv is ready to take on the creation and maintenance of the
modules owners list. He feels that the data would be most easily
maintained in a wiki, because of its low friction editing process.
5. To satisfy the "feels like definitive policy" requirement, Gerv
suggests the wiki page can be labelled as non-authoritative, and he is
willing to periodically copy its date to
http://www.mozilla.org/owners.html or its successor page on
www.mozilla.org. This would be an automated process, but triggered
manually - so only done based on a known good version. The copy at
www.m.o would be authoritative.
6. When the revitalization of www.m.o reaches the point of having an
easy to use (or at least easier-to-use) content management system we can
revisit the question of where the data is edited.
(For those interested in governance details, I'm writing this post as a
peer of the Module Ownership sub-module; after checking with the other
peers and the owner. If this was a policy decision, such as requiring
that the list be public, I'd make that as the owner of the governance
module. I know that module owners and peers don't necessarily get this
specific and I'm not sure I always will either. But since the
governance module and module ownership sub-modules are new I thought it
might be helpful to be explicit and specific at the beginning.)
Mitchell
davidwboswell
> strongly about definitiveness and www.m.o whether you feel
> item 5 is important enough to warrant the effort.
Copying the data from the wiki to www.m.o would be a hassle, but I
think it is worth the effort until we get to item 6. I'm also happy
to help Gerv with this process if that makes that step any easier.
David
Smokey Ardisson
> Summary of Action Plan
The discussion on this topic occurred while I was offline, so I
apologize for the things that appear otherwise to be "late-stage boat-
rocking"; this is my first chance to comment on any of it :-(
> 1. We can't use despot for Mercurial without rewriting it. That
> project is not currently underway.
First, with the caveat that I've never used Despot so I don't know the
complete details of how it works but think I have some understanding
of how/what it does, I don't understand how Despot's inability to work
with Mercurial is at all relevant to generating the module owner
list. As I understand it, Despot does two things: maintain a set of
access restrictions on parts of the cvs tree (the so-called "closed
partitions", which is what I understand can't exist with Mercurial)
and maintain a database of modules and information about them (e.g.,
the owner, web page, paths where the source code might live). Are
these really so tightly integrated that the module database can't just
be updated as it always was? Will Despot fail just because some
module now (post-1.9.0) is developed in the same directory in mozilla-
central? Moreover, CVS isn't going away; sure, it's not being
post-1.9.0 used for a good swath of code, but even that code and its
tree hierarchies still exist in 1.9.0 (cvs trunk). Basically, I'm
confused by why this unrelated technical problem is the starting point
for "redoing the module owner list maintenance system"?
> 3. The options are creating this in thewww.m.osource tree, using CVS
> and perhaps the venerable - but not maintained - tool "Doctor," or (b)
> maintaining this in wiki.mozilla org. with appropriate access control.
>
> 4. Gerv is ready to take on the creation and maintenance of the
> modules owners list. He feels that the data would be most easily
> maintained in a wiki, because of its low friction editing process.
If Despot non-functional for this purpose, the next question seems to
be does the module information really change so frequently that
importing a current copy of owners.html into www.m.o cvs (and making a
few changes now and then) is more work than creating the list anew in
a wiki and updating it there?
> 5. To satisfy the "feels like definitive policy" requirement, Gerv
> suggests the wiki page can be labelled as non-authoritative, and he is
> willing to periodically copy its date tohttp://www.mozilla.org/owners.htmlor its successor page onwww.mozilla.org. This would be an automated process, but triggered
> manually - so only done based on a known good version. The copy atwww.m.owould be authoritative.
I'm fully in the camp that the authoritative version must live on www.m.o,
and that if a non-authoritative version exists elsewhere, it must
regularly be synced to the authoritative version housed with other
policy documents.
Beyond the general issue with authoritativeness of wikis, there's the
specific issue here that wiki.m.o looks like an absolutely utterly
unorganized MESS. Things keep moving, there's no consistent style,
there's no editorial vision, much of the content becomes dated, etc.,
so that the end result looks like a scratchpad or how her heirs found
Emily Dickinson's poetry. Ease of editing also brings with it these
serious downsides (for policy-type documents); the state of the
surroundings do bear on how we view other items.
However, building on my comment after point 3/4, I again wonder
whether creating a separate wiki version that Gerv will edit and then
sync with www.m.o is really easier (and less work) than simply
maintaining only one copy on www.m.o. To me it seems that (even
without Doctor) pulling the one requisite file and making a few HTML
edits to it on occasion and then 'cvs commit' is far easier than
recreating the list on a wiki, updating it, and then migrating those
updates to www.m.o. I'm not Gerv, and clearly he sees this
differently, but this stuck me as odd and I wanted to point it out
because it seemed so odd.
> 6. When the revitalization ofwww.m.oreaches the point of having an
> easy to use (or at least easier-to-use) content management system we can
> revisit the question of where the data is edited.
Again, if Gerv is the gatekeeper in both cases, this doesn't make a
lot of sense to me. If the goal is to let module owners make changes
themselves, I understand, to a point, but at the moment the proposed
system (as I understand it) doesn't allow for that; Gerv is the
gatekeeper (maintaining the wiki page and updating the authoritative
page on www.m.o), and in that case surely having only one copy,
authoritatively maintained on www.m.o as always, is the simpler (and
better) solution?
I apologize again for all of the late "this doesn't make sense; please
explain" comments; had I been online for this discussion (instead of
just for its summary) I would have made the comments then.
Regardless, thanks to Gerv for stepping up and agreeing to do all the
work!
Smokey
Mike Shaver
<smokey....@gmail.com> wrote:
> On Jul 21, 7:13 pm, Mitchell Baker <mitch...@mozilla.com> wrote:
>> Summary of Action Plan
>
> The discussion on this topic occurred while I was offline, so I
> apologize for the things that appear otherwise to be "late-stage boat-
> rocking"; this is my first chance to comment on any of it :-(
>
>> 1. We can't use despot for Mercurial without rewriting it. That
>> project is not currently underway.
>
> First, with the caveat that I've never used Despot so I don't know the
> complete details of how it works but think I have some understanding
> of how/what it does, I don't understand how Despot's inability to work
> with Mercurial is at all relevant to generating the module owner
> list.
I agree; despot isn't controlling Mercurial access today, and we're
not suffering for it. The source-access-control part of despot is the
least important by far; the maintenance of the owners list and the
ability for owners to self-serve changes to their modules is what
we're after here.
> Beyond the general issue with authoritativeness of wikis, there's the
> specific issue here that wiki.m.o looks like an absolutely utterly
> unorganized MESS.
I don't think anyone is suggesting that we use wiki.m.o for this; I
certainly wasn't, as one of the wiki advocates, and others like Justin
Dolske specifically disclaimed that as being their proposal.
(wiki.m.o is indeed a disaster from an infrastructure point of view,
and I have hopes that we'll be in a position to improve it once we get
MDC's current upgrade sorted out.)
> However, building on my comment after point 3/4, I again wonder
> whether creating a separate wiki version that Gerv will edit and then
> sync with www.m.o is really easier (and less work) than simply
> maintaining only one copy on www.m.o.
We don't want to lose the ability for owners and multiple despots to
make quick changes to the owners list to clarify or fix errors. That
ability is used frequently to keep the owners list from being stale,
and bottlenecking it through Gerv helps no-one.
> Again, if Gerv is the gatekeeper in both cases, this doesn't make a
> lot of sense to me. If the goal is to let module owners make changes
> themselves, I understand, to a point, but at the moment the proposed
> system (as I understand it) doesn't allow for that;
I understand the current proposal to be that we use a wiki page with
restrictions on editing, but not that it be restricted to Gerv alone.
I would expect that all owners and despots would be able to edit the
page. If it is to be restricted to Gerv alone, that wasn't clear, and
I would object to that as well.
Mike
Gervase Markham
>> Beyond the general issue with authoritativeness of wikis, there's the
>> specific issue here that wiki.m.o looks like an absolutely utterly
>> unorganized MESS.
>
> I don't think anyone is suggesting that we use wiki.m.o for this; I
> certainly wasn't, as one of the wiki advocates, and others like Justin
> Dolske specifically disclaimed that as being their proposal.
What other wikis are available?
The idea is that the wiki version is the "easy-edit" part, and I write a
script to move the data to www.mozilla.org, which is the authoritative
part. That script would automate the process, but it would only be run
at times when we were confident that the wiki version was correct.
This way, we get the best of both worlds - easy editing, and an
authoritative version. And so, as the wiki version is not authoritative,
I don't see a problem using wiki.mozilla.org for it.
What have I missed?
> (wiki.m.o is indeed a disaster from an infrastructure point of view,
> and I have hopes that we'll be in a position to improve it once we get
> MDC's current upgrade sorted out.)
Just out of interest, what's wrong with it? You can create pages, and
people can edit them, it looks reasonably nice, and the syntax is fairly
simple. What more do you need from a wiki?
> We don't want to lose the ability for owners and multiple despots to
> make quick changes to the owners list to clarify or fix errors.
In fact, we want to gain that ability. In practice, we don't seem to
have it now - if we did, the list wouldn't get so dated.
> I understand the current proposal to be that we use a wiki page with
> restrictions on editing, but not that it be restricted to Gerv alone.
Indeed not. I offered to do the initial work of setting it up, but I
wouldn't expect to be gatekeeper for properly authorized edits.
Gerv
Gervase Markham
> Copying the data from the wiki to www.m.o would be a hassle, but I
> think it is worth the effort until we get to item 6. I'm also happy
> to help Gerv with this process if that makes that step any easier.
It's not really a hassle; a script to do it would be fairly simple. I'm
happy to write that, and then run it at carefully-chosen times when we
are happy with the data quality.
Gerv
Mike Connor
> Mike Shaver wrote:
>
>>> Beyond the general issue with authoritativeness of wikis, there's the
>>> specific issue here that wiki.m.o looks like an absolutely utterly
>>> unorganized MESS.
>>>
>> I don't think anyone is suggesting that we use wiki.m.o for this; I
>> certainly wasn't, as one of the wiki advocates, and others like Justin
>> Dolske specifically disclaimed that as being their proposal.
>>
>
> What other wikis are available?
>
> The idea is that the wiki version is the "easy-edit" part, and I write a
> script to move the data to www.mozilla.org, which is the authoritative
> part. That script would automate the process, but it would only be run
> at times when we were confident that the wiki version was correct.
>
Is wiki markup so much easier than just editing raw HTML? To the point
where we'll have two lists which may or may not be in sync at any given
time?
I don't actually understand why we can't just continue to use despot to
auto-generate content until we have a decent CMS backing www.m.o. I
don't think the timeline on that happening is so long that we need to
change processes twice (and if it is, I am somewhat sad about it).
> This way, we get the best of both worlds - easy editing, and an
> authoritative version. And so, as the wiki version is not authoritative,
> I don't see a problem using wiki.mozilla.org for it.
>
As it stands, we already have a working solution, which even though it
isn't optimal in the Hg world, at least works in the same way it has for
years, and doesn't need immediate replacing. Once www.m.o has a CMS, we
should be good...
-- Mike
Benjamin Smedberg
>> We don't want to lose the ability for owners and multiple despots to
>> make quick changes to the owners list to clarify or fix errors.
>
> In fact, we want to gain that ability. In practice, we don't seem to
> have it now - if we did, the list wouldn't get so dated.
I don't understand. Module owners can currently make changes to their
modules, and "despots" can make changes globally. The question of whether it
*is* maintained isn't really related to whether, technically, it can be edited.
--BDS
Mitchell Baker
dbaron has gone through and done a cleanup of the module owners list at
least once, so I asked him about why things get so outdated if people
can edit. His best guess was that a lot of people don't know they can
do this, most people never use despot, editing the list requires using a
tool and finding a password that is not in the normal flow of work and
it doesn't happen.
And in general I would say that whether something technically can be
edited is only part of the question. The other parts are how awkward it
is and how much special needs to be done.
I think we're past the point of arguing that people will use despot to
keep the module owners list up to date. We have years of experience
that says we don't do this. That's unlikely to get better now.
so it seems to me the choices are living with the list as more-or-less
up to date as it has been, or changing how we do it.
mitchell
Benjamin Smedberg
> dbaron has gone through and done a cleanup of the module owners list at
> least once, so I asked him about why things get so outdated if people
> can edit. His best guess was that a lot of people don't know they can
> do this, most people never use despot, editing the list requires using a
> tool and finding a password that is not in the normal flow of work and
> it doesn't happen.
Hrm. I have always presumed that the modules were not edited because nobody
ever reminded the module owners to edit them. Module owners really have
little incentive to keep the list up to date, and I expect most experienced
contributors hardly ever look at owners.html, because we know who owns what
code through everyday interactions on IRC.
I was surprised to learn recently that I was listed as owner of the
storage/sqlite code because that code happened to be lumped together with
toolkit. I expect that if somebody sent me a monthly reminder of the form
"here are the modules you own and are a peer of, please look through to make
sure the details are still correct" you'd get an immediate uptick in
correctness.
I'm not arguing against the wiki solution; I'm just skeptical that by itself
it will make anything better.
--BDS
Mike Shaver
<benj...@smedbergs.us> wrote:
> I'm not arguing against the wiki solution; I'm just skeptical that by itself
> it will make anything better.
Yeah, I don't think we have a technology problem, and strongly suspect
that whatever we do to make owners aware of a new wiki/CMS/etc.
solution can be used to raise awareness of the existing despot system.
WORKSFORME
Mike
Gervase Markham
> Hrm. I have always presumed that the modules were not edited because
> nobody ever reminded the module owners to edit them. Module owners
> really have little incentive to keep the list up to date, and I expect
> most experienced contributors hardly ever look at owners.html, because
> we know who owns what code through everyday interactions on IRC.
But of course this is a barrier to entry to new contributors.
Particularly if owners.html is actively wrong.
I wonder how many times someone has come along with a patch, figured out
that the process is that they need to request review, requested review
from someone listed in owners.html but no longer with the project, and
then lost interest when their patch was ignored?
> I was surprised to learn recently that I was listed as owner of the
> storage/sqlite code because that code happened to be lumped together
> with toolkit. I expect that if somebody sent me a monthly reminder of
> the form "here are the modules you own and are a peer of, please look
> through to make sure the details are still correct" you'd get an
> immediate uptick in correctness.
We could do that, either instead or additionally.
Gerv
Gervase Markham
> On Wed, Jul 23, 2008 at 11:55 PM, Benjamin Smedberg
> <benj...@smedbergs.us> wrote:
>> I'm not arguing against the wiki solution; I'm just skeptical that by itself
>> it will make anything better.
>
> Yeah, I don't think we have a technology problem,
Well, I have a technology problem :-) I want to annotate the list with
the Bugzilla components which are associated with each module, as a
stepping stone to doing something about old reviews. Currently that
involves either extending the (old and effectively unmaintained) Despot
software, or scraping multiple pages (as there's no unified list) or
owners.html.
When I suggested extending despot, Reed gave me a list of reasons why
it's not going to be useful for maintaining the module owners list and
its association with particular directories for much longer:
https://bugzilla.mozilla.org/show_bug.cgi?id=441271#c5
I believe he's already started a project to reimplement a new despot for
Hg which does the access control part but (at least, as currently
planned) not the module owner tracking part.
The conclusion seemed to be that extending despot wasn't the right way
to go, because its continued life in that role was limited. If that's
not, in fact, the case, perhaps we need to reconsider.
Gerv
Gervase Markham
> Is wiki markup so much easier than just editing raw HTML?
I was anticipating using wiki templates, which IMO are definitely easier
than poking around in 150 copies of the same large block of table markup.
{{Module|name=Bugzilla
|owner=Dave Miller
|source=webtools/bugzilla
|newsgroup=mozilla.dev.apps.bugzilla
...
}}
{{Module|name=Build and Release Tools
|owner=...
}}
...
> To the point
> where we'll have two lists which may or may not be in sync at any given
> time?
That's a feature. The easy-edit one would be marked as non-authoritative.
Gerv