Re: web site access mechanisms (was _real_ long subject)

[ ...and this is Stephen's reply back to me. *To be perfectly clear:* This message, while it appears to be from John S Jacobs Anderson <jacobs(a)azstarnet.com&gt; is actually from Stephen J. Turnbull <turnbull(a)sk.tsukuba.ac.jp&gt;. Sorry for any confusion. jsja] As far as I can tell the message I received was a private reply to me, only. Was that your intent? If not, feel free to borrow what ever you find useful from this message (or repost it to the list, for that matter). "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: john> Is there somewhere this 'Review Board' business is john> explained? I've seen it referred to a couple of times and I john> gather it's basically the XEmacs Cabal (there is no john> cabal). Is this correct? No. There is a Review Board. It is implemented as a closed mailing list, xemacs-review(a)xemacs.org. The members are the "brought to you by" list, more or less. They also have CVS commit access to the entire source tree. The procedure of operation is not clear to outsiders, nor to members, I suspect, but members do seem to have the right to "veto" a patch they don't like. Overriding a veto would presumably get messy; I don't think there is a standard procedure. When the board first was formed, there were a couple of patch wars where a given patch flipped in and out of the code base every few hours. (It wasn't as bad as it sounds, there were real changes to the patch each time. But the parties were, ah, ideologically motivated to find problems with the opposite solution. IIRC, the patches were never commited, it was just "I veto" "I resubmit and override your veto" back and forth, although there were threats to actually commit a patch while the other guys were asleep.) Membership is by invitation from the Cabal^H^H^H^H^HReview Board. john> That is, a person _ultimately_ (but not necessarily john> _personally_) responsible This is a principle that should be observed more throughout. john> It seems like having someone do this type of stuff would be john> another step towards getting more developer time towards john> development. Tiggers bounce, developers code. That's what they do. The problem is that we need to get some (probably non-developers) the responsibility for the Information Ministry (how Stalinist! ;-), and the authority (including commit access and xemacs-review membership) needed to make it work. We had a massive battle over ChangeLog entries. The forces of Right won (no changelog, the patchbot rejects your submission out of hand with a polite message about the need for a ChangeLog entry). I think the Information ministry probably ought to be notified of UI and API changes (things that should go into NEWS). Developers are going to like that even less, because it's harder to write up. Viz the package mess. john> Actually, the directory structure is going to change as john> little as I can help it, (from what it is right now). I've john> seen ump-teen links to www.xemacs.org during my link john> gathering expeditions, which was why the old mess of content john> is still there -- so those links don't break. OK, well that's good then. One obstacle to CVS down. john> Yes, that's a good place to send stuff that needs to go john> up. I plan on 24 to 48 hour turnaround for any and all john> submissions; just send it. Don't worry about HTML if you john> don't want to, I can do that easily too. I don't recommend you go there; submissions should be patches on existing files. We want to know who wrote what, so that if something uninterpretable gets out there, we know who to ask. We want to be able to revert to previous history if a design change just doesn't work out. That's where CVS helps. john> Of course, if you've got access, feel free to do it john> yourself, also. Send me a note and let me know, or at least john> modify the comments in the page header. (Add another <META john> type="author"> tag.) Write some standards. Make your job easy. If somebody sends you something, and you want to make an exception because "somebody" is your mother, feel free. If you really feel guilty, write a mode (but there are already several good HTML-editing modes). But the developers are used to coding to standard, and most people who are willing to submit doc patches probably would be too. Things like the <META TYPE="author"> tag. And how to do it. Commenting style. Etc. john> Files aren't going to move. OK. john> I guess the Review Board would get updates for file adds and john> file mods, too, but do they care? If they have commit authority on the documentation base, and they probably should. These are the people doing things like implementing the package system, porting to Win32 APIs, etc. They're the logical people to write the first big drafts of documentation for those. I recently wrote a book with 3 other authors, and having it under CVS really helped. I could see who committed when, and what they committed. I felt much less defensive about letting people edit my chapters. "Last patch wins" and I knew how to revert to "my" version. john> We've already got the submission/confirmation part (mail john> webmaster(a)xemacs.org stuff, I (or somebody else) posts it, john> we tell you it's posted). The only advantage to CVS would be john> (1) maintaining a local 'source' tree for the web site and john> (2) making sure two people weren't editing the file at the john> same time. john> Is that worth the effort, or is there something I'm missing? Well, I think that for packages and other add-ons, individual maintainers should have direct access to the Web site. I argued above for review board access. I think that access will be (or evolve that way) narrow enough to work, but broad enough that submission/confirmation will be a pain in the neck for the Webmaster. I think that having the history of changes is a good thing. I think it's worth it; we (somebody on the list) know how to implement it. It shouldn't impose too much on you, until it's actually ready to fly. It is possible to check for things like "author tags" in CVS. It should even be possible to demand that the submitter have a tag corresponding to him in the file (take a little work, that). -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules." -- ------------------------------------------------------------------------ John S Jacobs Anderson Apprentice Geek jacobs(a)azstarnet.com Journeyman Molecular Biologist <URL:http://www.treefort.org/~jacobs/> <- GeneHack:bioinfo*linux*opinion