É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.
> 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 practice. > 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 alone! > >> 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).
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
