12:14 p.m.
[I tried to send to the list last night and mistakenly sent it only to
Stephen. So, here it is for the list; follow-ups trimmed down. 8^)=
Also, with his permission, I'll be bouncing Stephen's reply to me back
to the list. The next message from me is actually from him. jsja.]
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
>>>>> "Jan" == Jan Vroonhof
<vroonhof(a)math.ethz.ch> writes:
We're not talking about making the Web site publically writable. I
think a reasonable thing to do would be to include the Webmaster on
the Review Board, add general responsibility for documentation to his
portfolio, and help him find volunteers to do those parts of the
documentation he didn't volunteer to do. (The reason for doing this
is to have somebody who will yell about changes to the docs that screw
his stuff up.) And he can add a couple of team members as he likes as
Web staff (who would not be review board members).
Is there somewhere this 'Review Board' business is explained? I've
seen it referred to a couple of times and I gather it's basically the
XEmacs Cabal (there is no cabal). Is this correct?
I do think a Minister of Information-Dissemination type position is a
good idea. That is, a person _ultimately_ (but not necessarily
_personally_) responsible for the FAQ, coordinating the documentation
versions and formats, announcing releases to Freshmeat and the
newsgroups, evangelism and proselytizing, etc., etc. It seems like
having someone do this type of stuff would be another step towards
getting more developer time towards development.
Or maybe the developer-type people prefer to handle this themselves?
And maybe the "last patch wins" rule should be removed for
the Web
site ;-)
Definitely a good idea, IMHO. 8^)=
Yes, I wonder about whether it will cause drag on design operations.
Remember, XEmacs's directory structure changes only slowly, but we can
expect that the Web site's directory structure will change fairly
often, at least for a while.
Actually, the directory structure is going to change as little as I
can help it, (from what it is right now). I've seen ump-teen links to
www.xemacs.org during my link gathering expeditions, which was why the
old mess of content is still there -- so those links don't break.
Jan> Yes, but our current problem is (or better was) one of
Jan> content, I can write all the READMEs , installation notes,
Jan> little items telling people there is know problem with
Jan> version so-and-so of the mule-base package but I have no way
Jan> of getting it to the site.
That's true for review board members; but the rest of us will still be
limited to xemacs-patches (or something equivalent?
webmaster(a)xemacs.org?), I presume.
Yes, that's a good place to send stuff that needs to go up. I plan on
24 to 48 hour turnaround for any and all submissions; just send
it. Don't worry about HTML if you don't want to, I can do that easily
too.
Of course, if you've got access, feel free to do it yourself, also. Send
me a note and let me know, or at least modify the comments in the page
header. (Add another <META type="author"> tag.)
One of the points of CVS is that if you (as Webmaster) do move a
file,
CVS will tell other authorized users, mostly the Review Board, that
you have moved the file. A CVS wizard could set it up so that nobody
but the Web maintainer could move files, I believe. Only the Web
maintainer should be allowed to do that kind of thing, of course.
I'm not sure why this is a Good Thing. Files aren't going to
move. Files might get added, content might get changed, but files
won't move, because then URLs break and that's Bad. I guess the Review
Board would get updates for file adds and file mods, too, but do they care?
Jan> Well, I respect your opinion and I promise to leave you
alone
Jan> while you do your work. However when your work has stabilized
Jan> I would like you to consider a solution that allows multiple
Jan> people to work on the website, if need be[1]. A solution that
Jan> no longer makes the maintenance[2] of the website dependent
Jan> on one (or a few) persons time. For me such a solution is
Jan> CVS, it isn't perfect but we already have the infra structure
Jan> in place.
I would go the opposite direction. Under normal circumstances,
everybody with CVS commit access to the sources should have equivalent
access to the Web site. Eg, someone who maintains packaged Lisp
should have check-in access to a set of pages (possibly a
subdirectory, depending on how tight artistic control the Webmaster
wants to maintain) devoted to the package they maintain. Maintainers
of binary kits might also have their own pages.
I respect what Jan is asking for. I also admit up front that my
practical knowledge of CVS is zero (read: never used it).
However, I don't see how doing what sounds like a reasonably
complicated amount of work to set up CVS buys. As Stephen says, public
write access, or wide-spread write access isn't all that desirable, so
you're going to need some kind of submission/confirmation system, much
like the current patch list.
We've already got the submission/confirmation part (mail
webmaster(a)xemacs.org stuff, I (or somebody else) posts it, we tell you
it's posted). The only advantage to CVS would be (1) maintaining a
local 'source' tree for the web site and (2) making sure two people
weren't editing the file at the same time.
Is that worth the effort, or is there something I'm missing?
Jan> [2] Note: That is maintenance, _not_ design. I think we
are
Jan> disciplined enough to keep a make minor (but possibly crucial
Jan> information wise) changes in accordance with your style
Jan> guides if you are on that round the world trip.
I don't know if I'm on 'that round the world trip', as I'm not sure
what that is. I do know that if you're going to spend time laying out
an intelligent and workable (IMNSHO) design, it's important to use
that as consistently as possible, across the whole site. Otherwise,
you end up confusing and frustrating your users.
It seems as if a working solution might lie with the use of extensive SSI
in the next version of the template. That way, the design, such as it
is, isn't really accessible from the template, and it becomes much
easier to add content, and make it apparent who the author is, etc.,
etc. The template can even be made publicly available for download, so
that people who want to add stuff can grab it, fill it out, and send
it in. Conceivably, a web interface to this could be setup which would
auto-mail stuff to webmaster(a)xemacs.org. (Ohhh...that's an idea to
remember, I think...)
CVS-guru's: Can the CVS system check to make sure a particular feature
exists in a file before it's accepted for check-in? That is, if an
Author: type field is defined, can check-ins of files lacking that
field be blocked?
Anyway, that's about it for now, I think. Changes sent to me today
didn't get made, but will be made no later than 2400 MST/1700 UTC
tomorrow.
Good night,
john.
--
------------------------------------------------------------------------
John S Jacobs Anderson Apprentice Geek
jacobs(a)azstarnet.com Journeyman Molecular Biologist
<URL:http://www.treefort.org/~jacobs/> <- GeneHack:bioinfo*linux*opinion