[pydotorg-www] project plan

skip at pobox.com skip at pobox.com
Wed Apr 21 19:18:39 CEST 2010


    skip> * (Agility) I don't think the site content is difficult to update.

    >> Right, so it involves at least use of subversion and understanding of
    >> reStructured Text format - plus checkin rights or the ability to
    >> create a patch.

All of which I (personally) can do within the confines of an (X)?Emacs
session with no need to recall svn or patch syntax.  OTOH, if your text
editing tool of choice is Notepad I can understand why this would be a
barrier to entry.  Personally, if you gave me a through-the-web way of
editing the site content the first thing I would do would be to figure out
how to get the content into Emacs.

I think you need to survey the potential contributors to see what they use
today for text editing and editing web content before throwing out the
current system.  I suspect most of the people who would contribute to the
site on more than a casual basis will already have some working knowledge of
version control systems and lightweight markup like ReST.

Whatever you come up with also has to fit into the release toolchain, as I
believe a significant amount of site content (and arguably the most
important content on the site) is generated at release time.

    Rich> I agree with Michael - as someone that is getting familiar with
    Rich> the process it just doesn't seem as agile as it could be.

Sorry, I don't know what "agile" means in this context.

    Rich> For instance, if there was a decision to add 5 new sections with
    Rich> 30 pages of content, which method would be faster for updating - a
    Rich> through-the-web-based approach or the existing create files, check
    Rich> in, build?

You're asking me to choose between:

  * edit locally using familiar tools, build the site locally using "make",
    review, edit, checkin

  *  one-by-one creation of upwards of 30 pages (where does the nascent
     content go for review before deployment?)

I know what I'd choose.  The bulk of those 30 pages will still be plain text
and to the greatest extent possible you have to allow people to edit that
content using their weapon(s) of choice.  If they perceive the process as
too cumbersome they will not contribute.  I understand that I may be making
your argument for you, however, on the one hand you have a certain amount of
content now, and a certain set of people who do maintain and update that
content.  Is it worth it to make it more difficult for existing contributors
to keep things running so you can attract some other (unspecified) people as
contributors who are or might be put off because the current tools are
perceived as too hard to learn/master?  I think it becomes a bird-in-the-
hand vs two-in-the-bush situation.

I will admit my only recent through-the-web editing experience is the Moin
text editor (which content quickly goes straight into Emacs) and general
<textarea> widgets (which should be taken out and shot as far as I'm
concerned).  I have tried (a long time ago) to use Zope to build a website
but quickly gave up (slow, complex, cumbersome).  Perhaps things have
improved in that area, but if there's no decent way to plop raw content into
a text editor I will likely take a pass.

    Rich> Maybe the way to approach this question is thinking about who
    Rich> could be editing the content. Should it always be technical
    Rich> individuals or should someone with writing skills be able to
    Rich> update the site as well?

Though we might wish it to be otherwise I suspect the bulk of the site
updates will always rest with much the same group of people as we have
today.  They will remain mostly programmers and most of the content updates
will fall into three categories: download/release, news items, and job
postings.  You might well have a full-scale reorganization of the site over
the next several months, but once the dust settles and you enter a new
steady state those three areas will likely still be the parts of the site
which change most frequently.

Perhaps a quick svn log would be useful as a way to understand how the site
changes today?  What parts of the site don't get the love they deserve
because the people who might be tempted to take ownership are put off by the
current workflow/toolchain?

Skip


More information about the pydotorg-www mailing list