[Python-Dev] Python wiki

Stephen J. Turnbull stephen at xemacs.org
Tue Sep 28 02:41:57 CEST 2010

Éric Araujo writes:
 > Le 25/09/2010 10:20, anatoly techtonik a écrit :

 > > Python ML are:
 > > 1. require dedicated admin to update, who is not a member of the group
 > > 2. don't have search
 > > 3. don't have optional thread subscription
 > > That's already enough to seek better platform for collaboration.
-------------- next part --------------

 > This is debatable.  Google Groups require a Google account, are not
 > controlled by python-dev, require JavaScript to view the archives, don?t
 > send MIME digests.  The public archives for python.org MLs are indexed
 > by Web search engines and are therefore searchable.

Indeed.  Mailman doesn't require a dedicated admin to operate, only to
set up.  Some things go better if you've got part-time admins
(moderation in particular).  I agree with techtonik that a better
platform is apparently needed, but this is a client-server system, and
the problem is in the client.  Ie, he should upgrade his MUA to one
that does threading properly, and allows priorities to be given to
threads.  (Emacs/Gnus is the one I'm familiar with but surely there
are others.)  This is a contextual judgment, not an absolute:
apparently most Python devs *do* use sufficiently powerful MUAs for
their purposes.  It makes sense for the minority to adopt the majority

 > Re: thread subscription, there is a setting about topics in the mailman
 > admin but I don?t understand it.

Mailman topics are a clumsy Subject-based filter, and require admin
intervention to set up.  They're quite valuable for low-to-medium-
traffic lists with a variety of more or less defined topics (ie, if
there were more traffic, you'd want to split the list), but are pretty
much useless for this purpose.

 > > Community can perfectly manage the stuff without dedicated admins if
 > > there is a gameplay in it.
 > I don?t agree with the split between admins and community.  Admins are
 > just trusted people from the community (which includes python-dev).

No, they're not just trusted people.  They're trusted people with
greater privilege than the rest of us, and therefore a bottleneck for
some operations.

 > > My advice - subscribe people editing page by default (a checkbox near
 > > submit button).

 > +1 wholeheartedly.

That default needs to be user-configurable.  I would not want to be
spammed with typo corrections on a page where all I did was correct a
typo.  I probably wouldn't even want to see major changes by default:
I came, I saw, I conquered the typo and got my info, now leave me

 > >> With an admin team behind it, you can also make more use of ACLs to
 > >> flag certain parts of the wiki as "official" by making them only
 > >> editable by certain people

 > I don?t know if this would be noticed enough to change the image of the
 > wiki.  I had started reviewing and updating all pages pertaining to
 > distutils and distutils2 some months ago, and I viewed the wiki as a
 > collaborative area to hash things out, before they can become official
 > code or docs.

I don't think we want to change the image of the wiki (as in "anybody
can edit")!

What we may want is (1) to make it easy for those with the authority
to update the official docs (but there's a very good story for putting
them in a repo, perhaps associated with the sources, so this is a weak
argument for reference-docs-in-wiki), and (2) make it easy for readers
to cross reference the community documentation (often more detailed or
less intimidatingly formal) and the reference manuals.  (1) *may*
suggest using the wiki engine to support editing, but I think most
devs are strongly against that.  (2) suggests using the wiki engine to
easily or even automatically set up cross-references.  I think that
wiki is probably the best technology for this purpose at the present
time, but I don't know if it's worth the effort to make the official
documentation wiki-friendly (in the sense of allowing the wiki to
generate links to community documentation from the reference manuals).

More information about the Python-Dev mailing list