Module Owners List
Gervase Markham
to use, which leads to the list getting regularly out of date. We have
discussed this in the past, but never quite reached a conclusion.
Here's my proposal for fixing this:
https://wiki.mozilla.org/Modules:Proposal
In order to allow people to comment better, the proposal comes with an
implementation of the wiki part of the system, which you can look at:
https://wiki.mozilla.org/Modules
We are looking for feedback, in particular on which of the two possible
mechanisms, as outlined in the proposal, for ensuring the reliability of
the list is to be preferred.
Thanks,
Gerv
Ehsan Akhgari
link to the discussion/rationale for each change in its summary, and that
way many more people can watch that wiki page and revert the changes if
their summary has no indication of the validity of a change. And since it's
a wiki, if someone mistakenly reverts something, the changes are still not
lost and can be re-applied if necessary.
--
Ehsan
<http://ehsanakhgari.org/>
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
Justin Wood (Callek)
I think the first option is good enough for us as well, *but* I do have
one problem on the technical rather than procedural side. The
peers/owner names are not e-mail-linkified like on owners.html. I'm not
sure how we _want_ that to remain, but I've used it many times in the
past to "Ok, so bob is a peer, but heres his e-mail for bugzilla fields"
--
~Justin Wood (Callek)
Dan Mosedale
first mechanism seems fine, and I think Ehsan's suggestion about
requiring rationale links in the editing is a fine one.
I have a couple of other thoughts here, but I don't think addressing
them should in any way get in the way of replacing despot with the macro
system you already have in hand.
* I find the existing format hard-to-read. Some thoughts from a
designer on how to improve that sound worthwhile.
* Because the despot system was such a pain and not very free form,
Thunderbird, Firefox, toolkit, and calendar all have additional separate
pages with sub-modules that are more up-to-date. As an example, see
<https://developer.mozilla.org/en/Mailnews_and_Mail_code_review_requirements>.
Longer term, do we even want all this stuff on the same page?
Dan
Robert Kaiser
> * Because the despot system was such a pain and not very free form,
> Thunderbird, Firefox, toolkit, and calendar all have additional separate
> pages with sub-modules that are more up-to-date. As an example, see
> <https://developer.mozilla.org/en/Mailnews_and_Mail_code_review_requirements>.
SeaMonkey also has its own sub-module list (not that it is too much
up-to-date, though).
Robert Kaiser
Mark Banner
Even if we don't want to linkify them, then we could perhaps having
which aliases everyone is in bugzilla, e.g. :standard8 :callek etc.
Standard8
Mark Banner
> * I find the existing format hard-to-read. Some thoughts from a designer
> on how to improve that sound worthwhile.
I can think of lots of ways, including dynamic search and dynamic
expansion as you drill down the various places.
> * Because the despot system was such a pain and not very free form,
> Thunderbird, Firefox, toolkit, and calendar all have additional separate
> pages with sub-modules that are more up-to-date. As an example, see
> <https://developer.mozilla.org/en/Mailnews_and_Mail_code_review_requirements>.
> Longer term, do we even want all this stuff on the same page?
I think we have too much stuff to put all on the same page, especially
in its current format.
I have suggested before that we have at least one page which lists links
to the various review requirements where appropriate, maybe now is the
time to do that on this page.
Standard8
Gervase Markham
> I think the first option is good enough for us as well, *but* I do have
> one problem on the technical rather than procedural side. The
> peers/owner names are not e-mail-linkified like on owners.html. I'm not
> sure how we _want_ that to remain, but I've used it many times in the
> past to "Ok, so bob is a peer, but heres his e-mail for bugzilla fields"
They can be linkified; see the example here:
https://wiki.mozilla.org/Template:Activities_Module
I didn't linkify them on the test page because it would have taken a
long time.
Gerv
Gervase Markham
> * I find the existing format hard-to-read. Some thoughts from a designer
> on how to improve that sound worthwhile.
Presumably you mean the HTML rendering rather than the wiki markup? :-)
Yes, I'd be happy to hear from a designer, although I don't know if
MediaWiki would restrict the inclusion of arbitrary CSS.
> * Because the despot system was such a pain and not very free form,
> Thunderbird, Firefox, toolkit, and calendar all have additional separate
> pages with sub-modules that are more up-to-date. As an example, see
> <https://developer.mozilla.org/en/Mailnews_and_Mail_code_review_requirements>.
> Longer term, do we even want all this stuff on the same page?
So we have two choices:
1) Stick it all on the same page, take it for granted that anyone
wanting information is going to search rather than read, so the page
length is relatively unimportant;
or
2) Have sub-pages for each part of the code, meaning pages are shorter
but it's more likely that people might end up looking on the wrong page.
I guess if we really wanted this to be properly searchable we'd write a
web app; but then we might be spawning an eventual son-of-Despot... And
what works now trumps what would be better but doesn't exist.
Gerv
Justin Wood (Callek)
> On 14/07/10 18:52, Dan Mosedale wrote:
>> * I find the existing format hard-to-read. Some thoughts from a designer
>> on how to improve that sound worthwhile.
>
> Presumably you mean the HTML rendering rather than the wiki markup? :-)
> Yes, I'd be happy to hear from a designer, although I don't know if
> MediaWiki would restrict the inclusion of arbitrary CSS.
It does, but you can edit the site-wide, wiki-stored css file(s) as a
sysop/bureaucrat which at least you [and I] are.
>
>> * Because the despot system was such a pain and not very free form,
>> Thunderbird, Firefox, toolkit, and calendar all have additional separate
>> pages with sub-modules that are more up-to-date. As an example, see
>> <https://developer.mozilla.org/en/Mailnews_and_Mail_code_review_requirements>.
>>
>> Longer term, do we even want all this stuff on the same page?
>
> So we have two choices:
>
> 1) Stick it all on the same page, take it for granted that anyone
> wanting information is going to search rather than read, so the page
> length is relatively unimportant;
>
> or
>
> 2) Have sub-pages for each part of the code, meaning pages are shorter
> but it's more likely that people might end up looking on the wrong page.
>
> I guess if we really wanted this to be properly searchable we'd write a
> web app; but then we might be spawning an eventual son-of-Despot... And
> what works now trumps what would be better but doesn't exist.
I'd go with 1, provided we properly order the list in the first place
(list despot does now). I for one have always searched when needed, and
I feel that is far more useful in this setup than the other option.
Of course, the sub-module review requirements might still be better
listed separately, or even letting them be *edited* separately and the
wiki transcludes them.
--
~Justin Wood (Callek)
Dan Mosedale
> On 14/07/10 18:52, Dan Mosedale wrote:
>> * I find the existing format hard-to-read. Some thoughts from a designer
>> on how to improve that sound worthwhile.
>
> Presumably you mean the HTML rendering rather than the wiki markup?
> :-) Yes, I'd be happy to hear from a designer, although I don't know
> if MediaWiki would restrict the inclusion of arbitrary CSS.
> So we have two choices:
>
How about:
3a) keep the existing subpages
b) make a single page that directs people to the sub-pages
c) create a new Misc page and only migrate stuff from Despot to it that
doesn't already have a home on one of the other pages.
d) encourage owners to migrate to the new macros over time (where
applicable)
e) maybe even use wiki transclusion to generate one monster big page
from the sub-pages
Despite the fact that this has a bunch of steps, I _think_ this is
actually the least amount of work of all the options proposed so far...
Dan
Gervase Markham
> Here's my proposal for fixing this:
> https://wiki.mozilla.org/Modules:Proposal
This seems to have met with general approval, and a lack of objection,
so I will move forward with implementing this plan (although that may
not now happen until after my wedding, so i.e. in September).
Gerv
Justin Wood (Callek)
Unrelated: Congrats!!!
--
~Justin Wood (Callek)
Gervase Markham
> 3a) keep the existing subpages
> b) make a single page that directs people to the sub-pages
> c) create a new Misc page and only migrate stuff from Despot to it that
> doesn't already have a home on one of the other pages.
> d) encourage owners to migrate to the new macros over time (where
> applicable)
> e) maybe even use wiki transclusion to generate one monster big page
> from the sub-pages
I guess we could do all that.
Can people comment with the URLs of existing sub-module-owner pages?
Gerv
Max Kanat-Alexander
> Can people comment with the URLs of existing sub-module-owner pages?
For Bugzilla, it's:
https://wiki.mozilla.org/Bugzilla:Owners
-Max
Dave Townsend
Will there still be a way to view all modules on a single page? It's a
bit of a pain to have to know which section the module you're searching
for is in.
Gervase Markham
> Will there still be a way to view all modules on a single page? It's a
> bit of a pain to have to know which section the module you're searching
> for is in.
There is now :-)
https://wiki.mozilla.org/Modules/All
Gerv