[pydotorg-www] project plan
steve at holdenweb.com
Wed Apr 21 20:24:31 CEST 2010
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.
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/
More information about the pydotorg-www