[Python-Dev] Python wiki

[Paul Boddie]

Hello,

I've been following this thread all week at work, but I thought it might be 
time to respond to the different remarks in a single response, given that I 
am involved in editing and maintaining the Wiki on python.org, and I had a 
strong enough opinion about such things to give a talk about it at EuroPython 
that some of you attended:

http://wiki.europython.eu/Talks/Web_Collaboration_And_Python/Talk

Guido van Rossum wrote:
> On Thu, Sep 23, 2010 at 3:35 PM, "Martin v. Löwis" <martin at v.loewis.de> 
wrote:
> > There actually is an admin team, and they actually do set ACLs.
>
> Who are they?
>
> > IIUC, this is primarily for spam protection, though.
>
> So would they object against additions to the team?

The administrators are generally the people on the following page:

http://wiki.python.org/moin/AdminGroup

Someone may have special powers, particularly if they have shell access to the 
machine running the Wiki, but there's no "secret brotherhood". In fact, I 
recall advocating that Carl Trachte get admin powers given his continuing 
high-quality contributions, so we can say that people aren't denying others 
administrative privileges if that person is clearly doing good work and would 
benefit from being able to have those privileges.

[Later on...]

Guido van Rossum wrote:
> On Fri, Sep 24, 2010 at 3:31 AM, Michael Foord
>
> <fuzzyman at voidspace.org.uk> wrote:
> > Wiki maintenance is discussed, along with other python.org maintenance
> > topics, on the pydotorg-www mailing list:
> >
> > http://mail.python.org/mailman/listinfo/pydotorg-www
>
> Which has hidden its membership (even to members). Does it really need
> to appear that secretive? At least the message archive is open and has
> all the usual suspects.

As we're now seeing, people don't feel that it's acceptable to publish the 
subscribers list, and I think that it's a complete distraction to seek to do 
so, anyway. It's not as if everyone on that list has special privileges and 
is preventing newcomers from joining it.

> > More wiki and website maintainers needed!
>
> Maybe a prominent wiki page with info about how to join the list and
> the responsibilities / needs would help?
>
> Also, I gotta say that the wiki login process is awkward.

MoinMoin supports OpenID, although I did find and report issues with Moin 1.9 
in this regard. Something on my now-huge list of things to do is to make Moin 
authentication better, especially where there might be a choice of 
authentication methods.

Georg Brandl wrote:
> Am 23.09.2010 22:25, schrieb anatoly techtonik:
> > On Thu, Sep 23, 2010 at 6:57 PM, Barry Warsaw <barry at python.org> wrote:
> >> I certainly agree with that.  So, how can we solve those problems? 
> >> Radomir has shell access now so perhaps we can ask him to make the
> >> Python wiki theme more visually appealing.  What roadblocks do people
> >> encounter when they want to help garden or reorganize the wiki?
> >
> > First of all Wiki is outdated. Correct me, but python.org specific
> > customizations are not modules, but patches that makes it hard to
> > update the Wiki to latest version or add new customizations.
>
> That's why we have a Moin core developer on the team.  ISTM that Moin 1.x
> is notoriously hard to extend -- once you go beyond plugins adding new wiki
> macros -- which is part of what the team wants to fix in 2.x.

Although I understand the sentiments about "specific customizations", 
python.org should only have its theme as something that isn't a generic 
extension to MoinMoin, and that theme should be actively maintained. When 
python.org switched its architecture a while ago, the special theme 
presumably came with the deal, but it's been so out of date for so long that 
I switched to one of the standard themes years ago. Fortunately, Radomir's 
EuroPython theme is actively maintained, works with recent MoinMoin releases, 
looks a lot better than the old theme, and is used elsewhere.

As for Moin 1.x being "notoriously hard to extend" beyond macros, you can get 
a long way with macros and actions, although I agree that sometimes it's 
possible to hit architectural constraints.

> > Second - ugly Creole syntax. I am for inter-cooperation between wikis,
> > and I understand that for non-developer communities [] symbols
> > imposing problems, but as an open source developer I am addicted to
> > Trac and Google Code syntax and never had problems with those.
>
> This isn't Creole syntax, it's Moin wiki syntax.  And face it, it's not
> going to change.  It's also not so much different from Trac wiki syntax.

I never agreed with this complaint, anyway. When discussing this previously 
with Anatoly, I went as far as to ask on #moin where Radomir actually posted 
a good summary of the syntax differences:

http://wiki.python.org/moin/SiteImprovements/WikiSyntaxComparison

I invite anyone to justify claims that the old style (which Trac adopted) was 
better. Complaints about double bracketing are specious: MediaWiki has 
different bracketing levels and it's really confusing.

> > Fourth. GPL license. I personally don't have interest to waste my time
> > for the code I won't be able to use in some projects, unless the
> > project is either exceptional (Mercurial) or interesting. To make
> > python.org MoinMoin interesting - there should be an inviting
> > entrypoint (see point three above) and the list of tasks to choose
> > form. Something that is better than
> > http://wiki.python.org/moin/SiteImprovements
>
> Yes, that needs to be updated indeed.

On the matter of the GPL, Anatoly and I more or less agreed to disagree when 
we last discussed the Web site. On the matter of site improvements and the 
page which attempts to document ideas, we could move such things to a tracker 
(where they will probably get as much attention as the Web site bugs get 
right now), or we could actually prune a lot of the issues by addressing them 
with fixes that are readily available (applying to a lot of "xyz doesn't 
work" complaints). Getting people to accept that things aren't going to 
change for the sake of it (like the Wiki syntax) is more difficult, but at 
some point such discussions just have to end.

anatoly techtonik wrote:
> That's a dead way. Wiki should be open for everyone. Just need more
> people subscribed to revert unwelcome changes. That is to make
> timeline more visible, because on wiki.python.org it is _not_
> intuitive. It may worth to see how Mercurial wiki is managed - I've
> picked up the bookmarks monitoring habit from it. Maybe a design
> change will help, but again - there is no entrypoint for people with
> design skills to start.

The Wiki is generally "open for everyone", but as I noted in my talk you often 
get people who decide that their opinion is worth more than the cumulative 
knowledge and experience of everyone who has been maintaining a particular 
resource [1]. You also have to prevent spamming and vandalism which is quite 
well taken care of with the TextCha support, although I accept that 
mechanisms should be in place to promote users to higher levels of privilege 
after a while - another little project on my long "to do" list - so that they 
don't have to answer editing questions.

As for the Mercurial Wiki, I have some involvement with that, and I don't see 
how it is significantly differently managed. I've also proposed various 
changes to that Wiki including a theme that could be deployed straight away, 
but I suspect that it's more a case of people being too busy to take me up on 
any such offer than a malicious cabal denying me the chance to improve a 
particular Internet resource.

Some final notes on the matter of Wiki editing:

The Wiki has for a long time been a product of many co-existing contributions 
that occasionally overlap with each other and are tied together as 
respectfully and gently as possible. Although there is a temptation to 
overhaul much of the content, respect for the existing structure and content 
has mostly restrained any cleaning-up attempts. I wouldn't mind a bit of 
reorganisation, but that brings us to the role of the Wiki.

If other resources are meant to provide the bulk of what people consider 
the "important" content, then the Wiki will always have to be shaped to 
respect that; if the Wiki is to hold much of that content, then issues such 
as navigability become even more critical. But what is certain is that 
tucking the Wiki away in some obscure location (I had to request that a link 
to it be re-added to the front page of python.org recently, as I recall) and 
treating it like a playpen will only encourage casual edits with little 
concern for the resulting quality. Anyone now on the verge of concluding that 
this is purely a Wiki phenomenon should consult my "common myths" slide:

http://wiki.europython.eu/Talks/Web_Collaboration_And_Python/Talk#Some_Common_Myths

High-quality documentation isn't something you get for nothing, nor is it a 
property of some magic solution or tool: there's always some hard work 
involved for human beings.

Paul

[1] One "happy" memory of mine involves someone who decided that their style 
and terminology edits were so important that they felt the need to tell 
me "don't modify it again" when it was they who were doing the modifying.