- 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.
> - 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.
Mitchell Baker wrote: > 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.
Gervase Markham wrote: > Mitchell Baker wrote: >> 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.
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?
Benjamin Smedberg wrote: > 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.
Gervase Markham wrote: > Benjamin Smedberg wrote: >> 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.
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.
> 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.
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.
davidwboswell wrote: > 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.
davidwboswell wrote: >> 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.
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.
Benjamin Smedberg wrote: > davidwboswell wrote: >>> 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.
> 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.
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.
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.
fantasai wrote: > Benjamin Smedberg wrote: >> davidwboswell wrote: >>>> 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.
>> 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.
> 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.
Mitchell Baker wrote: > 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.
Yes I agree that seems a lot of trouble. We have a wiki. It has page 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.
Justin Wood (Callek) wrote: > Mitchell Baker wrote: >> 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.
Mitchell Baker wrote: > 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.
Justin Wood (Callek) wrote: > 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.
> 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.
>> 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.
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.
> 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"
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.
On Tue, Jul 8, 2008 at 3:25 PM, davidwboswell <davidwbosw...@yahoo.com> 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?
> 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!
> 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.
Mike Beltzner wrote: >> 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.
> 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.
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:
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.
>>> 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.
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.
Mitchell Baker wrote: > 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.
On Jul 7, 11:20 pm, Mitchell Baker <mitch...@mozilla.com> wrote:
> 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.
|
