Despot and the Module Owners List
Gervase Markham
- The current incarnation of despot <http://despot.mozilla.org/>, our
system for managing module permissions, is coming to the end of its
useful life. We are moving to Hg, and despot only works with CVS - so
can no longer effectively control access or be a canonical source of
information. Despot also doesn't integrate with our LDAP infrastructure.
A rewrite has been suggested:
https://bugzilla.mozilla.org/show_bug.cgi?id=353463
- Associating new information with the module list requires extending
despot, which is time-consuming. E.g. I want to map Bugzilla components
to modules as a first step in dealing with old reviews. In order to do
this and store the information alongside the module list (to avoid it
getting out of sync), despot would have to be extended.
- We have just renewed the Committer's Agreement, and Harvey Anderson
(MoCo lawyer) has said that it would be OK to have people agree to it
electronically, relieving all the paperwork shuffling burden and
eliminating delays. This would hopefully enable us to get all SCM-using
contributors to sign the agreement without complaints that it's
bureaucratic and slows things down. A tool is needed to perform this
function.
Proposal:
- Move the tracking of modules, associated with their owners, peers,
newsgroups, documentation, Bugzilla components and anything else, to a
(machine-parseable) wiki page. The creation of modules and the
assignment of owners and peers would be done by the owners of the Module
Owners module.
- Rebuild despot to keep track of Committer's Agreements, vouchers, SSH
keys, and permissions for the remaining modules where possible and
appropriate[0] (integrated with LDAP and Hg) on a per-contributor basis.
Advantages:
- (Over putting all info in a new despot) The smaller despot-ng is and
the less it does, the quicker it'll get written.
- Module data is kept more up to date. Even a quick glance at despot
shows stale data for e.g. newsgroup associations. It can also be
extended as necessary.
- Committer's Agreement process gets a lot smoother and easier for all
involved.
Disadvantages:
- Requires writing code. But we need it anyway.
- I can't think of any, but perhaps other can.
Related bug: https://bugzilla.mozilla.org/show_bug.cgi?id=363542
("Determine best home for Module Owners List -- still despot?")
Gerv
[0] bsmedberg says: "We really don't need and can't have
per-directory access control in mercurial repos."
https://bugzilla.mozilla.org/show_bug.cgi?id=441271#c10
Mitchell Baker
1. Should we move the tracking of modules and module owners from despot
to a wiki rather than rebuild despot to do this?
2. Should we rebuild despot to keep track of other stuff
Gerv, is there a reason these are tied? Can we decide item 1 separately
from item 2?
mitchell
Gervase Markham
> Seems to me there are two topics here.
>
> 1. Should we move the tracking of modules and module owners from despot
> to a wiki rather than rebuild despot to do this?
>
> 2. Should we rebuild despot to keep track of other stuff
>
> Gerv, is there a reason these are tied? Can we decide item 1 separately
> from item 2?
They are tied only because the solution to one or both involves
rebuilding despot in some fashion or other. But yes, we could try and
decide them separately.
Gerv
Benjamin Smedberg
I don't understand why topic 1 involves rebuilding despot at all. Sounds
more like "stop using despot"... just use a wiki page, perhaps protected.
I'm a little nervous about the phrase "machine-readable". I think that a
machine-readable wiki page isn't worth the trouble, because of the amount of
extraneous data that would be required. Can't it just be a human-readable
list of modules?
--BDS
Gervase Markham
> I'm a little nervous about the phrase "machine-readable". I think that a
> machine-readable wiki page isn't worth the trouble, because of the
> amount of extraneous data that would be required. Can't it just be a
> human-readable list of modules?
All I mean by that is that we try and make the markup consistent enough
that a machine could parse it. Perhaps we might use templates (I haven't
looked into those yet, but they seem to work well on other MediaWiki
installations I've visited).
I'm not suggesting that we sacrifice the look or the usability of the page.
Gerv
Axel Hecht
Just as a datapoint, not necessarily the best example, but
http://wiki.mozilla.org/L10n:Bugogram is actually machine readable. I
made some compromises, but as long as you stick roughly to one format,
action=raw enables one to parse those pages fairly well.
Axel
davidwboswell
> Sounds more like "stop using despot"... just use a wiki
> page, perhaps protected.
In terms of where a module owners list ends up living, I think it
makes the most sense to keep it on www.mozilla.org instead of putting
it on a wiki.
The new vision of www.mozilla.org is for it to be a community portal
and a place to host official content and policy documents. Having the
module owners list on the site will help us aggregate these official
pages and make them easy to find.
When we had the discussion about the new site vision, it also seemed
that there was a general consensus that wikis weren't the right place
for official content (even if you did lock down who can make edits)
since there is a very informal feel around wikis.
I understand though that there are some issues that are unique to the
module owners list because of despot, so using www.mozilla.org may not
be technically feasible.
David
Gervase Markham
> In terms of where a module owners list ends up living, I think it
> makes the most sense to keep it on www.mozilla.org instead of putting
> it on a wiki.
>
> The new vision of www.mozilla.org is for it to be a community portal
> and a place to host official content and policy documents. Having the
> module owners list on the site will help us aggregate these official
> pages and make them easy to find.
I agree with this. The only disadvantage is that the way www.mozilla.org
is built means that you'd basically be maintaining and editing a static
HTML file, using copy and paste to create new entries. You couldn't use
wiki technology like templates to keep the formatting and layout of the
entries consistent.
Gerv
Benjamin Smedberg
>> I don't understand why topic 1 involves rebuilding despot at all.
>> Sounds more like "stop using despot"... just use a wiki
>> page, perhaps protected.
>
> In terms of where a module owners list ends up living, I think it
> makes the most sense to keep it on www.mozilla.org instead of putting
> it on a wiki.
Per https://bugzilla.mozilla.org/show_bug.cgi?id=441271#c11 I think Brendan
disagrees.
I don't think anyone cares which domain name the list appears on, but making
it easy to maintain with a low barrier to entry seems quite important,
especially since the module ownership module owners are all busy people.
--BDS
fantasai
CVS in inconvenient unless you do a lot of editing on the site, but
tweaking an existing page via Doctor is pretty easy, assuming you
have access to the page.
~fantasai
Mitchell Baker
fundamental to our approach. I agree completely that our policy
documents need to be identified clearly and treated as special. I
wonder if this is dependent on the www location?
It's clear that the module owners list -- mozilla.org policy documents
in general -- should be in a place that
(1) is clearly "official"
(2) is clearly "policy", representing a sense of "this is how things are
at this moment" rather than "this is under construction" and
(3) is not editable by anyone
[(4) probably access- controlled]
This could be done with a wiki; it could be done through an html only
system like we use on www.mozilla.org.
David, are you thinking that the "www" in the URL gives people a better
sense that something is policy than a "wiki" in the URL?
Access-controlled wikis are a lot easier to edit than even doctor. Or
are you thinking that it's harder to get a wiki to look and feel like
the contents are official and can be changed only by identified people?
I'm not set on either answer, but this seems like a good discussion.
mitchell
Justin Wood (Callek)
> hmm, I'm wondering if the form of editing/display needs to be
> fundamental to our approach. I agree completely that our policy
> documents need to be identified clearly and treated as special. I
> wonder if this is dependent on the www location?
>
>
> It's clear that the module owners list -- mozilla.org policy documents
> in general -- should be in a place that
>
> (1) is clearly "official"
> (2) is clearly "policy", representing a sense of "this is how things are
> at this moment" rather than "this is under construction" and
> (3) is not editable by anyone
> [(4) probably access- controlled]
>
> This could be done with a wiki; it could be done through an html only
> system like we use on www.mozilla.org.
>
> David, are you thinking that the "www" in the URL gives people a better
> sense that something is policy than a "wiki" in the URL?
> Access-controlled wikis are a lot easier to edit than even doctor. Or
> are you thinking that it's harder to get a wiki to look and feel like
> the contents are official and can be changed only by identified people?
>
> I'm not set on either answer, but this seems like a good discussion.
>
Well, I'm not david, but I agree that "wiki.mozilla.org" feels less
official.
Also a wiki [at least mediawiki] can easily be made to look official
enough for this, it just needs Wiki UI stripped from whatever theme we
were to use. And we'd need a separate theme for editors to use, and
access-control the theme to be special for authorized editor logins, so
that editors can use and see the needed wiki-bits, non-editors get a
basic, "This is the page" view.
That said I feel a special wiki install just for this plus the dev time
for a suitable skin [set] is not worth the trouble it would cause.
--
~Justin Wood (Callek)
Mitchell Baker
specific access control. We could have a section for policy that was
clear about this.
It's not as polished as what you suggest. but we'll need something
special for www as well, unless every page there is official.
my big issue is that www.mozilla.org is a non-starter without the
"doctor" tool. And that is a tool myk wrote for me years ago, and is
not a maintained tool. Myk did the last security fix it needed because
it was a security fix and so it had to be done. but that's not in Myk's
current interest, it's not his job, and it's not the area he's really
excited about volunteering in.
So if we want to use www.mozilla.org going forward, i would add as a
requirement that someone has to step up to maintain doctor, or we need
to find a different mechanism that allows editing of the website without
the full check-in process. If we can do that then things are much easier.
mitchell
Myk Melez
> So if we want to use www.mozilla.org going forward, i would add as a
> requirement that someone has to step up to maintain doctor, or we need
> to find a different mechanism that allows editing of the website without
> the full check-in process.
Personally, I think the doctor should retire. He's been seeing patients
for an awfully long time now, but he hasn't updated his skillset to keep
up with recent advances in medicine.
Meanwhile, that wikch doctor who recently set up shop is much more
approachable and has become more popular, even if his prescriptions can
be incoherent at times.
Surely he'll mature into the accomplished physician we need faster than
our old doc will be able to learn new tricks.
-myk
Justin Dolske
> Well, I'm not david, but I agree that "wiki.mozilla.org" feels less
> official.
Yeah, this has come up before in other discussions about where
"official" policy stuff should live. I think it's a fair concern,
although I'm not sure it's right to block on this broad issue for the
issue at hand.
Have the folks doing the mozilla.org site reorig considered rolling a
Wiki into the mix? Seems like a wiki could live along side the existing
static content.
Justin
Mike Beltzner
> Have the folks doing the mozilla.org site reorig considered rolling a
> Wiki into the mix? Seems like a wiki could live along side the
> existing
> static content.
Like, uh, wiki.mozilla.org? :)
cheers,
mike
Michael Connor
On 8-Jul-08, at 12:55 PM, Justin Dolske wrote:
Or just make www.m.o a wiki, and just make sure the site design makes
it feel authoritative.
wiki.m.o is by design a random scratchpad with few restrictions on
what goes where, and who owns what. www.m.o ideally has a pretty
clear access control policy, maybe even a clear hierarchy, but it
could easily be wiki-based.
MDC has shown that you can have "wiki" and "authoritative" in the same
sentence, so I don't think this is a problem.
-- Mike
davidwboswell
> policy documents in general -- should be in a place that
>
> (1) is clearly "official"
> (2) is clearly "policy", representing a sense of "this is how things
> are at this moment" rather than "this is under construction"
Providing a clearly marked area for official documents is something we
are looking at for the design work on www.mozilla.org that will be
starting soon.
The current version of the site doesn't offer this, so I certainly
understand why there is a desire to put these pages in other places
that are easier to edit and are currently easier for people to find.
> David, are you thinking that the "www" in the URL gives people a
> better sense that something is policy than a "wiki" in the URL?
Yes, I think it makes a difference. Regardless of how access to a
page on a wiki is being handled, to me a wiki just doesn't feel like
the right place for policy documents.
It sounds like the solution is to make sure that there continues to be
an easy way to update www.mozilla.org pages without having to go
through CVS. I've added something about this to the www.mozilla.org
planning document and we'll discuss this at the next site planning
meeting.
http://wiki.mozilla.org/Mozilla.org:Planning#Editing_Pages
David
Mike Shaver
>> David, are you thinking that the "www" in the URL gives people a
>> better sense that something is policy than a "wiki" in the URL?
>
> Yes, I think it makes a difference. Regardless of how access to a
> page on a wiki is being handled, to me a wiki just doesn't feel like
> the right place for policy documents.
There are lots of web sites that are wikis under the covers, but don't
espouse the "wiki ethic" of free-and-easy edits. And as MDC has
shown, you obviously don't need to have "wiki" in the URL in order to
use wiki technology. How prominent the edit links are is just a
skinning choice, which is why you don't see them displayed strongly on
the front page of MDC (the front page not being something on which we
encourage edits), or on the front page of http://wiki.mindtouch.com/ .
All of that together is why I find it hard to believe that people
really care -- in the "how they relate to policy" sense of care --
whether someone uses a built-in text field and wikitext, a custom
CVS-web-hack, or another CMS in order to update a document.
Why are policy documents more important than other pieces of
information on which the community relies to make good decisions and
behave appropriately, like release schedules and bugzilla etiquette
and so forth? Are we really worried that someone will vandalize the
owners page, get someone inappropriate to approve a patch, and then
check in under that aegis? They could just check in without approval
in the first place!
Mike
Mike Beltzner
>>
> Providing a clearly marked area for official documents is something we
> are looking at for the design work on www.mozilla.org that will be
> starting soon.
Looking at the document types & structure at http://wiki.mozilla.org/Mozilla.org:Planning#Editing_Pages
, I'm not sure why any of those pages are more or less "official" than
any others. Can you expand on which you think are more or less so, and
why?
> The current version of the site doesn't offer this, so I certainly
> understand why there is a desire to put these pages in other places
> that are easier to edit and are currently easier for people to find.
>
>> David, are you thinking that the "www" in the URL gives people a
>> better sense that something is policy than a "wiki" in the URL?
>
> Yes, I think it makes a difference. Regardless of how access to a
> page on a wiki is being handled, to me a wiki just doesn't feel like
> the right place for policy documents.
Can I dig into this? Why is that? Is it the layout and presentation of
wikis? There is, to my knowledge, no reason why the current www.mozilla.org
content couldn't be 100% replicated on a wiki with no visual
difference. Even the "edit this" links can be removed, or better
still, hidden by CSS and only shown when someone logs into the site
(which itself can be via a single link presented on some page like www.mozilla.org/login)
.
> It sounds like the solution is to make sure that there continues to be
> an easy way to update www.mozilla.org pages without having to go
> through CVS. I've added something about this to the www.mozilla.org
> planning document and we'll discuss this at the next site planning
> meeting.
Right; so you need a CMS tool. Wiki is a CMS tool, and while the
default skin makes every page look like an article that can and should
be edited, there is no reason why that must be the case for every site
that uses a wiki as the CMS tool. Access control can also be strictly
relegated.
cheers,
mike
Justin Dolske
>> Have the folks doing the mozilla.org site reorig considered rolling a
>> Wiki into the mix? Seems like a wiki could live along side the existing
>> static content.
>
> Like, uh, wiki.mozilla.org? :)
The point was that while there might be a wiki under the content, it
would be at www.mozilla.org and not look wiki-like.
Justin
davidwboswell
> espouse the "wiki ethic" of free-and-easy edits. And as MDC has
> shown, you obviously don't need to have "wiki" in the URL in order to
> use wiki technology.
I think there are two different issues here. My original comment was
that I didn't think we should put policy documents on wiki.mozilla.org
and I still think that.
Then there's the issue of keeping things on www.mozilla.org and making
it easier to use (perhaps by using a wiki as a CMS for the site).
This was discussed in some detail when we were working out the new
site vision, so I don't want to rehash too much. Feel free to scan
through these posts:
http://groups.google.com/group/mozilla.governance/browse_thread/thread/c80ae5a9d622bc6a#
IMO, www.mozilla.org shouldn't be run on 1998-era technology forever,
but we can't realistically switch off of it in the near term. I don't
think it makes sense to talk about alternate CMSes until after we
archive off 10,000 or so pages and have a grasp on what a new www.mozilla.org
looks like. In the meantime, we need a place for policy documents to
live.
David
Chris Ilias
There are a few problems with www.mozilla.org; but I see it as a wiki
right now. With Doctor, anyone with a web-tree account can edit pages
via web interface. There's even a page history link at the bottom of
each page. And there are definitely certain files in the web-tree that
only a few have permission to edit.
If I understand correctly, the main problem is that getting the ability
to edit pages requires applying for a CVS account, including learning to
create your own SSH key.
But having docs on www.mozilla.org rather than wiki.mozilla.org is
currently the best and clearest indication of "officiality". This was
discussed at length in bug 345664 - "Deciding the future of
www.mozilla.org" <https://bugzilla.mozilla.org/show_bug.cgi?id=345664>.
Should we take this to mozilla.dev.mozilla-org?
Samuel Sidler
> It's clear that the module owners list -- mozilla.org policy documents
> in general -- should be in a place that
>
> (1) is clearly "official"
> (2) is clearly "policy", representing a sense of "this is how things are
> at this moment" rather than "this is under construction" and
> (3) is not editable by anyone
> [(4) probably access- controlled]
Definitely agree with this think you should add #4.
> David, are you thinking that the "www" in the URL gives people a better
> sense that something is policy than a "wiki" in the URL?
I don't think it necessarily has anything to do with the URL, more the
fact that people assume wikis can be editable by anyone. Regardless of
if we lock such a wiki down or not, it still implies easy-to-edit,
easy-for-anyone-to-change. Wikipedia gets slammed a lot for not
necessarily being reliable. Even pages which are locked down are
deemed questionable. They have the benefit of citing "true" documents.
We wouldn't.
> Access-controlled wikis are a lot easier to edit than even doctor. Or
> are you thinking that it's harder to get a wiki to look and feel like
> the contents are official and can be changed only by identified people?
I'm less concerned with this, personally. Making Doctor easier to use
sounds like a MoFo project in the making. Specifically, making parts
of the page editable using a standard RTF control.
-Sam
Samuel Sidler
> It's not as polished as what you suggest. but we'll need something
> special for www as well, unless every page there is official.
True, but this could easily be part of the redesign that's already
being worked on. Don't let that hold us back.
> So if we want to usewww.mozilla.orggoing forward, i would add as a
> requirement that someone has to step up to maintain doctor, or we need
> to find a different mechanism that allows editing of the website without
> the full check-in process. If we can do that then things are much easier.
I mostly concur, but I'd add that finding such a person probably isn't
hard, we just haven't really looked. It'll likely be outside of our
community, but there's nothing stopping MoFo from hiring a person to
work on Doctor for a month or two and make it exactly what it needs to
be.
-Sam
Samuel Sidler
> Personally, I think the doctor should retire. He's been seeing patients
> for an awfully long time now, but he hasn't updated his skillset to keep
> up with recent advances in medicine.
I mostly disagree.
I think there are clear problem with doctor, starting with his age,
but I think those are all issues that can be fixed in a relatively
short amount of time if that's what we choose to do.
Personally, I use Doctor quite a bit and I'd hate to see him go. If he
left, perhaps something like Kubla could replace him. Adding RTF
controls to Kubla is almost certainly more likely than improving
Kubla. (But isn't Kubla just Doctor in a different form?)
-Sam
Samuel Sidler
> > I don't understand why topic 1 involves rebuilding despot at all.
> > Sounds more like "stop using despot"... just use a wiki
> > page, perhaps protected.
>
> In terms of where a module owners list ends up living, I think it
> it on a wiki.
I fully agree.
> The new vision ofwww.mozilla.orgis for it to be a community portal
> and a place to host official content and policy documents. Having the
> module owners list on the site will help us aggregate these official
> pages and make them easy to find.
>
> When we had the discussion about the new site vision, it also seemed
> that there was a general consensus that wikis weren't the right place
> for official content (even if you did lock down who can make edits)
> since there is a very informal feel around wikis.
In one of my replies, I mention this. Specifically, Wikipedia often
feels "inaccurate" even with locked down pages.
> I understand though that there are some issues that are unique to the
> module owners list because of despot, so usingwww.mozilla.orgmay not
> be technically feasible.
I'm not sure what issues would be unique to the list that would make
them (all of which should have despot accounts and, thus, doctor
access) unable to update a page on www.m.o vs wiki.m.o.
-Sam
Michael Connor
On 8-Jul-08, at 10:49 PM, Samuel Sidler wrote:
> Mitchell Baker wrote:
>> David, are you thinking that the "www" in the URL gives people a
>> better
>> sense that something is policy than a "wiki" in the URL?
>
> I don't think it necessarily has anything to do with the URL, more the
> fact that people assume wikis can be editable by anyone. Regardless of
> if we lock such a wiki down or not, it still implies easy-to-edit,
> easy-for-anyone-to-change. Wikipedia gets slammed a lot for not
> necessarily being reliable. Even pages which are locked down are
> deemed questionable. They have the benefit of citing "true" documents.
> We wouldn't.
As said elsewhere, I think this is FUD at best. I haven't seen the
same accusations leveled at MDC, ever. And this is a situation where
the people on the ACL for a document would be the authorities for that
information, so I absolutely reject any implication that CMS A yields
more official-looking content than CMS B. We have the benefit of
having the authors of the doc be the people making the decisions and
writing the policies. The technology used for entering text and
converting it to a webpage should be absolutely irrelevant, since the
end content/URLs/etc should be functionally identical. Do people view
devnews as less canonical because its using Wordpress?
Of course, there's a difference between a wiki and a site using a wiki
for its CMS. I don't think anyone's saying we should have our
canonical and official project site on an actual wiki, but advocating
strongly for having using wiki software with proper ACL structures as
the CMS.
>> Access-controlled wikis are a lot easier to edit than even doctor.
>> Or
>> are you thinking that it's harder to get a wiki to look and feel like
>> the contents are official and can be changed only by identified
>> people?
>
> I'm less concerned with this, personally. Making Doctor easier to use
> sounds like a MoFo project in the making. Specifically, making parts
> of the page editable using a standard RTF control.
Why build our own CMS when there's dozens out there? This feels like
a waste of resources to me, and introduces delays for no obvious
reason. We could do the setup and start migrating content tomorrow if
we take something off the shelf like DekiWiki and do the reskinning in
parallel. This project seems to have been stagnating for a really
long time, and I would really love to see it move forward aggressively.
-- Mike
Mitchell Baker
-- rewriting despot for managing module owners
-- rewriting despot for managing the other things Gerv mentioned
-- getting and maintaining a good module owner's list
-- how we get policy documents to look official
-- the design and purpose and so on of the mozilla.org site
-- the technology we use for mozilla.org site(s)
I'll comment on despot separately.
I'd rather not address these in the context that item 4 (design and
purpose of the mozilla.org sites) is stagnating. Actually, there's been
more activity here now than for years. It's slow yes, but there are
plenty of reasons. It took ages to be able to get a plan on how to
handle the old content because people feel very strongly and very
differently. Then there's the discussion of what the mozilla.org site
is for, what's its purpose. Here's a link to at least part of that
discussion:
http://groups.google.com/group/mozilla.dev.mozilla-org/browse_thread/thread/96b7a4237ee25830/8980d110bb081a44#8980d110bb081a44
I'm glad that David is driving this, I certainly haven't been doing it.
I'm sure he wishes it were easier to get enough of us rounded up to
the same viewpoint to move faster. If it's a resource issue then yes,
we can be more aggressive in finding help. There may be plans for this
already though, now that basic decisions like handling of historical
content, approach, etc have been worked out.
So, where does that leave us?
Rather than argue over technology, it's probably more useful to describe
the traits of the result that we want. Then we end up with something
like a requirements document, and we can use that to evaluate technolgy
choices. Here I don't mean the prupose of the site, but traits around
the experience of using it (eg., "feels definitive where appropriate"
and "easy for appropriate people to edit")
I don't know if this work is already underway. If you know of it please
add a pointer.
Mitchell
fantasai
Ditto to all that. I agree completely.
~fantasai
Robert Kaiser
> Have the folks doing the mozilla.org site reorig considered rolling a
> Wiki into the mix? Seems like a wiki could live along side the existing
> static content.
Yes, and we concluded that everything that even has this wiki-style look
and big "Edit" buttons at least looks like everyone can change the
content anyway and therefore deducts that this cannot be really official.
Robert Kaiser
Mitchell Baker
Mitchell
Mike Beltzner
Good thing those bits can be eliminated with some simple CSS if not with Wiki configuration settings themselves, then. It sounds to me like your analysis used some assumptions that all Wikis must product content that look like MediaWiki or MDC.
Also, FWIW, the product plans for Firefox exist on wiki.mozilla.org. I *assure* you that the numbre of times we get people assuming that they are not canonical because they are on a Wiki is exceedingly rare. Also rare are times that people assume content posted to the MDC Wiki or any of the Planet Mozilla blogs is anything other than absolute gospel spoke from the mouth of the Mozilla dino himself. Far, far more common is the case that access control results in the entrusted people (myself included) allowing the documents (say, those aforementioned Firefox product plans) to fall deeply out of date.
Let me be clear: I'm not advocating for no access control, nor am I advocating for big shiny EDIT buttons and a look that is reminiscent of Wikipedia. I am merely suggesting that we have a proven technology that works well, is extremely malleable, and seems to fit your every bill. I am also suggesting that you shouldn't judge CMS software by its most frequently used covers.
cheers,
mike
davidwboswell
> already though, now that basic decisions like handling of historical
> content, approach, etc have been worked out.
I've submitted a proposal for the Summit to have a discussion about
the www.mozilla.org site. I think it would be a good opportunity to
present what's been done with the site lately and to have a
conversation about what comes next. For the part of this thread
that's been about the future of the site, it may make sense to
continue this discussion then.
David
Mitchell Baker
> davidwboswell wrote:
>>
>>
>> IMO, www.mozilla.org shouldn't be run on 1998-era technology forever,
>> but we can't realistically switch off of it in the near term. I don't
>> think it makes sense to talk about alternate CMSes until after we
>> archive off 10,000 or so pages and have a grasp on what a new
>> www.mozilla.org
>> looks like. In the meantime, we need a place for policy documents to
>> live.
>
> Ditto to all that. I agree completely.
>
> ~fantasai
Yes, we need a place to put policy documents, even separate from the
question of the module owners list.
Specifically, I need a place to put the new Incubator Repositories
policy. And its way past time to go though the docs linked from
www.mozilla.org/hacking, pull out those that are still official policies
and put them someplace where they can be found. bug is 444455
This is a separate issue from the technology that we end up using for
mozilla.org. My goal at this point to get these into the site we're
using today.
Anyone interested in helping figure out which of the documents on
/hacking still have relevance and should be included in a policy list
let me know.
mitchell
Gervase Markham
> it's probably more useful to describe
> the traits of the result that we want.
Here's a first attempt at the traits of a good module owner list, trying
to pull together thoughts from this thread and previous bugs. Note that
some of these may conflict with others, and not everyone might agree on
their relative importance.
0) Tracks module names, owners, peers and perhaps directories
1) Feels like definitive policy
2) Easy for appropriate people to edit
3) Either access controlled or easy to notice when illegally edited
4) Possible to find owner of a particular bit of code
5) Possible to extend or annotate in more or less official ways without
compromising definitiveness (e.g. associated newsgroups,
documentation, Bugzilla modules, ...)
Gerv
timeless
> Here's a first attempt at the traits of a good module owner list, trying
> to pull together thoughts from this thread and previous bugs. Note that
> some of these may conflict with others, and not everyone might agree on
> their relative importance.
>
> 0) Tracks module names, owners, peers and perhaps directories
> 1) Feels like definitive policy
> 2) Easy for appropriate people to edit
> 3) Either access controlled or easy to notice when illegally edited
> 4) Possible to find owner of a particular bit of code
> 5) Possible to extend or annotate in more or less official ways without
> compromising definitiveness (e.g. associated newsgroups,
> documentation, Bugzilla modules, ...)
0b) easy to find names of people to list.
[despot only allows despots to do user searches]
this is solvable w/ LDAP of course (not that i'm advocating it), but
please don't forget this problem. (No, I'm not asking for this feature
to be available for everyone, authentication is fine, but restricting
it to despots is probably too restrictive.)
With Bugzilla if i try to pick someone like ss, i might be unlucky and
get boriss instead. Now, I could in certain circumstances force
Bugzilla to confirm for me the identity, or i could do a search
elsewhere, but for something like this, it needs to be fairly easy for
someone trying to add a person to a list to figure out the right
person.
And before people think I'm claiming this is a mozilla.org problem,
keep in mind that someone might want to do a commit on my behalf and
pick the wrong address (for the record, the right address is @mozdev;
no, mail has not been delivered to me @bemail in many many years). So,
I'm well aware of the hazards of trying to find account info (or in
some cases too many accounts, yes, I obviously contribute to this
problem).
Gerv: while i know you started this thread, I think it got hijacked
and would have preferred that you used a new thread so that people
could easily track your messages.
Gervase Markham
> With Bugzilla if i try to pick someone like ss, i might be unlucky and
> get boriss instead. Now, I could in certain circumstances force
> Bugzilla to confirm for me the identity, or i could do a search
> elsewhere, but for something like this, it needs to be fairly easy for
> someone trying to add a person to a list to figure out the right
> person.
Right. If someone's primary Bugzilla user ID is not the email address
listed on the module owners page, their user ID also needs to be listed.
> Gerv: while i know you started this thread, I think it got hijacked
> and would have preferred that you used a new thread so that people
> could easily track your messages.
I've been talking to various people and have formulated a proposal,
which should be available in a few days. We'll make sure to post that as
a new thread so you can comment on it.
Gerv