Re: [Python-Dev] Python wiki
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:
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_Commo... 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.
On 25/09/2010 20:12, Paul Boddie wrote:
[snip...] 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,
To be fair, quite a few people said they thought it was fine / a good thing. A couple (maybe 3?) said that as the list was originally advertised with the member list hidden it would be unfair to change. So based on responses, more people think it *is* acceptable. So long as we give notice for the change, so that anyone who doesn't want their name associated with the list can unsubscribe, I don't see why there should be a problem. All the best, Michael
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.
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
>> As we're now seeing, people don't feel that it's acceptable to >> publish the subscribers list, Michael> To be fair, quite a few people said they thought it was fine / Michael> a good thing. A couple (maybe 3?) said that as the list was Michael> originally advertised with the member list hidden it would be Michael> unfair to change. So based on responses, more people think it Michael> *is* acceptable. I've not yet responded to this aspect of the thread. I see no reason not to make the membership list visible to the list members themselves. Beyond that, I don't think it serves any benefit, and of course, runs the risk of exposing email addresses to spam harvesters. OTOH, those of us who are visible enough on the web that we get to the point of helping maintain a very public website have probably already exposed our email addresses dozens or hundreds of times (or more) to spammers. Googling for "skip@pobox.com" (the quotes are required to constrain the search properly) yields about 22,000 hits. "guido@python.org" yields about 38,000 hits. Paul's and Michael's addresses returned multiple thousands of hits. And so on. As I recall, one reason for the formation of pydotorg-www was to create a more visible list than pydotorg so the maintenance of the website didn't appear so cabalistic to the interested observer. Still, I see that most/all lists hosted on mail.python.org seem to restrict the list membership to the list admins, so leaving the status quo probably won't hurt anything. Skip
Am 25.09.2010 21:12, schrieb Paul Boddie:
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 a disclaimer, I have no idea about the specific configuration of Moin used at wiki.python.org.
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.
It's just that every Moin installation I've come across used custom patches, and as a consequence was difficult to update. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Sat, Sep 25, 2010 at 12:12 PM, Paul Boddie <paul@boddie.org.uk> wrote:
Guido van Rossum wrote:
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.
Unfortunately, most sites using OpenID seem have an awkward login process. Maybe it's just me (I don't use OpenID much) but I expect that without a lot more handholding of new users, OpenID actually turns more people away than any other registration/login process. The people who like OpenID are often the ultra-geeks who cannot imagine the worldview of a typical internet user, and when they design a website they are often clueless about what it feels like to start using OpenID for the first time or to remember your OpenID handle if the last time you used it was a month ago. Not that the native Moin login method is much better... Either way, Python's wikis have some of the most awkward auth systems I've come across. -- --Guido van Rossum (python.org/~guido)
Unfortunately, most sites using OpenID seem have an awkward login process. Maybe it's just me (I don't use OpenID much) but I expect that without a lot more handholding of new users, OpenID actually turns more people away than any other registration/login process.
So how do you like the OpenID login of PyPI, which has a Google, MyOpenID and Launchpad icon, which users need to click on to create in account or login? The ultra geeks demanded and got a separate page where they can enter long URLs. Regards, Martin
On 9/25/2010 5:37 PM, Martin v. Löwis wrote:
Unfortunately, most sites using OpenID seem have an awkward login process. Maybe it's just me (I don't use OpenID much) but I expect that without a lot more handholding of new users, OpenID actually turns more people away than any other registration/login process.
So how do you like the OpenID login of PyPI, which has a Google, MyOpenID and Launchpad icon, which users need to click on to create in account or login?
The ultra geeks demanded and got a separate page where they can enter long URLs.
Having just tried this out. A few comments: 1) Registering via OpenID is a bit clumsy since there is a "Register" link that does not mention OpenID. 2) The URL registered with the OpenID provider is a bit of a wart: "http://pypi.python.org/pypi?:action=openid_return" vs. "http://bitbucket.org/" 3) The email I received asked me to "Complete your Cheese Shop registration" which I think is just an oversight since the relabeling to pypi. 4) It's a bit clumsy that "Login" pops up an HTTP Authentication prompt, which is useless to someone who only has never set a password and relies only on an OpenID credential. Furthermore, the 401 page does not provide a quick way to get to use OpenID. In general, I am pretty happy with pypi's support of OpenID considering it allowed me to use my own provider, which often has not been the case with other sites. My experience with trying to adopt OpenID as a way of life has been poor mostly because many sites fail to support anything but a few major OpenID providers (e.g., Google). I appreciate has a fast-path for those providers and yet let's me still use my own. Although, I think it would be nice if I didn't have to go to another page to do that, but I may be biased by having such a short OpenID URI. -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu
1) Registering via OpenID is a bit clumsy since there is a "Register" link that does not mention OpenID.
Thanks. Fixed.
2) The URL registered with the OpenID provider is a bit of a wart: "http://pypi.python.org/pypi?:action=openid_return" vs. "http://bitbucket.org/"
You mean, as this is what the provider then shows you for confirmation? Unfortunately, this can't be changed anymore, or many of the existing accounts break. When I started this, I was more unclear about the relationship of "realm" and "return URL" (I'm still unclear, not having used a realm yet).
3) The email I received asked me to "Complete your Cheese Shop registration" which I think is just an oversight since the relabeling to pypi.
Ok, fixed.
4) It's a bit clumsy that "Login" pops up an HTTP Authentication prompt, which is useless to someone who only has never set a password and relies only on an OpenID credential. Furthermore, the 401 page does not provide a quick way to get to use OpenID.
I think there is no way out wrt. to the basic auth prompt. I could label the "Login" link "Password login" if you think this would help. Preventing the browser from prompting the user on the chance they might want to enter an OpenID is not possible, and stopping to use basic authentication is not feasible.
In general, I am pretty happy with pypi's support of OpenID considering it allowed me to use my own provider, which often has not been the case with other sites.
I guess you are then not in the class of users Guido was referring to, but rather in the "ultra geeks" class. What regular user is actively searching for an "OpenID provider"? If you were using your facebook account (or some such) to log in (i.e. a service that "the masses" likely use and which happens to be an OpenID provider), I'd rather add another provider icon to the front page.
Although, I think it would be nice if I didn't have to go to another page to do that, but I may be biased by having such a short OpenID URI.
This is actually deliberate. I don't want to clutter the front page with a wide entry field. And again, enjoying a short OpenID URI probably does put you in the "ultra geek" category (which I seriously don't mean as an offense). I've learned that OpenID really is a mystery even to the fairly technical usership of PyPI. As an anecdote, a user was puzzled that, after registering the Google OpenID, all you need to do to login is to click on the google logo, and that no user interaction at all was required. This counters established expectations about security so much to actually confuse long-term internet users. Regards, Martin
On 9/26/2010 3:12 AM, Martin v. Löwis wrote:
2) The URL registered with the OpenID provider is a bit of a wart: "http://pypi.python.org/pypi?:action=openid_return" vs. "http://bitbucket.org/"
You mean, as this is what the provider then shows you for confirmation?
The provider also lists the trusted sites by these return URLs, and that is where I saw it as being a bit of a wart. I use the OpenID plugin for WordPress as my provider, so it may be that it doesn't do this correctly. I noticed that Google shows just "pypi.python.org", but the WordPress plugin shows that return URL instead. Nevertheless, I agree that it's too late/not worth it to change that now.
I think there is no way out wrt. to the basic auth prompt. I could label the "Login" link "Password login" if you think this would help.
The basic auth prompt doesn't bother me so much as the fact that the 401 doesn't have a "Use OpenID [Google] [myOpenID] [Launchpad]" set of links; you have to use the brower's back button because the only links offered are to register or reset your password.
Preventing the browser from prompting the user on the chance they might want to enter an OpenID is not possible, and stopping to use basic authentication is not feasible.
In theory, you could catch usernames that started with "http://", but I imagine that only "ultra geeks" know their URIs (I have no idea what the URI for a Google account is). But, I don't see this as being worthwhile either; I just think it would be nice if the 401 page gave a quick way to correct one's mistake that didn't involve the back button.
And again, enjoying a short OpenID URI probably does put you in the "ultra geek" category (which I seriously don't mean as an offense).
No offense taken. :) -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu
On Sun, 26 Sep 2010 21:56:20 -0400, Scott Dial <scott+python-dev@scottdial.com> wrote:
On 9/26/2010 3:12 AM, Martin v. Loewis wrote:
Preventing the browser from prompting the user on the chance they might want to enter an OpenID is not possible, and stopping to use basic authentication is not feasible.
In theory, you could catch usernames that started with "http://", but I
No, Martin really meant "not possible": once basic auth is started, the browser prompts for username and password and you are in basic-auth land thereafter; the web server has *no way* to tell the browser to *stop* using basic auth.
imagine that only "ultra geeks" know their URIs (I have no idea what the URI for a Google account is). But, I don't see this as being worthwhile
Well, my OpenId is 'david.bitdance.com', so even if you could get around the basic auth problem, looking for "http://" wouldn't work. -- R. David Murray www.bitdance.com
No, Martin really meant "not possible": once basic auth is started, the browser prompts for username and password and you are in basic-auth land thereafter; the web server has *no way* to tell the browser to *stop* using basic auth.
Yes, but Scott proposed that OpenID users might fill in their OpenID in the username field and leave the password field empty. Technically, this would work - the browser would then get the OpenID redirect in response to the original request.
imagine that only "ultra geeks" know their URIs (I have no idea what the URI for a Google account is). But, I don't see this as being worthwhile
Well, my OpenId is 'david.bitdance.com', so even if you could get around the basic auth problem, looking for "http://" wouldn't work.
Sure - however, it would actually be possible to determine that this is an OpenID: perform discovery on it. If that succeeds, try to establish a provider association; if that also succeeds, redirect the user to the OpenID login process. However, I'd rather not do that, since OpenID users don't expect that kind of interface. Providing OpenID links on the login failure 401 response is reasonable, though. Regards, Martin
On 9/26/2010 11:45 PM, R. David Murray wrote:
On Sun, 26 Sep 2010 21:56:20 -0400, Scott Dial <scott+python-dev@scottdial.com> wrote:
On 9/26/2010 3:12 AM, Martin v. Loewis wrote:
Preventing the browser from prompting the user on the chance they might want to enter an OpenID is not possible, and stopping to use basic authentication is not feasible.
In theory, you could catch usernames that started with "http://", but I
No, Martin really meant "not possible": once basic auth is started, the browser prompts for username and password and you are in basic-auth land thereafter; the web server has *no way* to tell the browser to *stop* using basic auth.
I agree that once you reply with a 401 that you will prompt the user, but my point was what "username" means in the Authorization header is open to interpretation by the HTTP server and/or script handling the GET request.
imagine that only "ultra geeks" know their URIs (I have no idea what the URI for a Google account is). But, I don't see this as being worthwhile
Well, my OpenId is 'david.bitdance.com', so even if you could get around the basic auth problem, looking for "http://" wouldn't work.
That's actually not a valid OpenID[1], but the OpenID specification says a relaying party "MUST" normalize identifiers[2] (in this case, prepending the "http://"). I believe bugs.python.org does this by checking for a username first(?), and failing any matches, it normalizes it for OpenID discovery. Otherwise, I can always use the canonical form of my ID "http://scottdial.com" to login (assuming ':' and '/' are illegal characters for usernames). I say all this not with the intent of saying pypi *needs* this, but to refute the notion that OpenID must be clumsy to use. [1] http://openid.net/specs/openid-authentication-2_0.html """ Identifier: An Identifier is either a "http" or "https" URI, (commonly referred to as a "URL" within this document), or an XRI (Reed, D. and D. McAlpin, “Extensible Resource Identifier (XRI) Syntax V2.0,” .) [XRI_Syntax_2.0]. """ [2] http://openid.net/specs/openid-authentication-2_0.html#normalization """ 3. Otherwise, the input SHOULD be treated as an http URL; if it does not include a "http" or "https" scheme, the Identifier MUST be prefixed with the string "http://". If the URL contains a fragment part, it MUST be stripped off together with the fragment delimiter character "#". See Section 11.5.2 (HTTP and HTTPS URL Identifiers) for more information. """ -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu
participants (8)
-
"Martin v. Löwis" -
Georg Brandl -
Guido van Rossum -
Michael Foord -
Paul Boddie -
R. David Murray -
Scott Dial -
skip＠pobox.com