[pydotorg-www] project plan

[Steve Holden]

skip at pobox.com wrote:
>     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?
> 
All good elitist stuff, Skip ;-).

The problems are as much structural as technical, as I tried to
demonstrate in my last message.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
See PyCon Talks from Atlanta 2010  http://pycon.blip.tv/
Holden Web LLC                 http://www.holdenweb.com/
UPCOMING EVENTS:        http://holdenweb.eventbrite.com/