[pypy-dev] Re: from private mail out of discussion on building a communitypythion website
lac at strakt.com
Thu Nov 20 04:22:06 CET 2003
Sourceforge won't let you develop using subversion until subversion is 1.0,
which is isn't, quite, yet. But once you have used subversion, the thought
of using cvs is ... painful ...
Plus, for the design I had in order, you really want to use subversion
as part of your versioning system from inside the website. There is
already a wiki based on subversion -- subwiki -- http://subwiki.tigris.org/
and kwiki and blosxom both support svn. These places might have code
we want to look at and see ...
Here is part of mail where Tim and I were discussing exactly what we
might want in a new website ....
>Laura, as for your concerns about community. The model we'd probably
>propose is a registration system (to stop bots from posting stuff) and a
>'broadcast delay' moderation system.
I am not sure about the 'to stop bots from posting stuff' rule.
Moshez Zadka has a really nice bot for logging irc conversations.
I could see a case where somebody _wanted_ a bot to be able to post
regular updates here. How much abuse do you get if you disallow this?
Also, I really really hate the 'having to log in' rule. I have way,
way, way too many sites, and I need to access them from all over the
world. So, naturally, I use the same password everywhere. A few
months ago, somebody who realised this, forged a bunch of articles
flaming Microsoft claiming to be from me. Quite funny, actually.
But whenever I see password protection, I think 'aha -- somebody has
a clubhouse. And only members of _my gang_ can use the clubhouse.
You need the magic password, to prove that you are in _my gang_ ...'
Can't we do something else?
>ie New posters content would be seen by other registered users but not
>by unregistered users. This could be combined in many ways to make very
>new people have to be fully moderated. People who have had one thing
>accepted only have a delay on publishing and more people can see the
>changes and finally trusted people can be published immediatly.
>Just wondering what you would think to that?
On first glance, I like my version -- there is are 2 versions of the
site, the official version, which is what everybody sees, and then the
'being hacked on' version, which you can see if you use a slightly
different url -- which is the one that you get when you edit, or try
to edit. Same structure underneath -- just if one were
www.python.biz/frontpage the other would be
and so on and so forth for every file on the website. Then, every
3 days or so, unless somebody/the readership/however we choose
to devolve authority/ votes it down, the changed versions become
the real versions. We would need a way for the changer to specify
-- NOT DONE YET, don't make this live in 3 days!
-- READY TO GO according to me
Care has to be taken so that two people can edit the same pages
concurrently -- and that different levels of fixes can go on at
the same time.
Thus if I decide to replace all instances of 'PBF' with
'The Python Business Forum' on the website, then I should get to get
my modifications in and out on the world globally, even if
somebody was revising a document that referred to the PBF, and
had the page out for editing. We want neither the 'last out
overwrite behaviour' -- then my PBF global change would get
rewritten by the revised document, which for argument sake would
still refer to things as the PBF -- nor do we want the reviser to
get to lock the file, thus making it impossible for me to make
a global PBF change at all because always there will be a file
locked and being edited.
You need real file versioning a la svn for this to work properly.
the other thing that I want, for a community website, is a way
of doing the workflow which is more like raising exceptions, and
less like testing your system calls to make sure they return the
correct status. That is to say, what I want is a way that everybody
can make all sort of changes, with the understanding that if we hate
what they did, we can always yell about it and go back to the old
version, as opposed to people needed the permission of a few overworked
webadmins to get anything done. But if we want to do that, we need
very precise control over how we can back out of things, and for
that we need a real version control system, and for that I want
More information about the Pypy-dev