[pydotorg-www] project plan

[Steve Holden]

Michael Foord wrote:
> On 21/04/2010 20:56, R. David Murray wrote:
>> On Wed, 21 Apr 2010 12:31:00 -0400, Richard
>> Leland<rich at richleland.com>  wrote:
>>   
>>> I agree with Michael - as someone that is getting familiar with the
>>> process
>>> it just doesn't seem as agile as it could be. For instance, if there
>>> was a
>>> decision to add 5 new sections with 30 pages of content, which method
>>> would
>>> be faster for updating - a through-the-web-based approach or the
>>> existing
>>> create files, check in, build? I'm not sure one is faster than the
>>> other and
>>> I'm sure there would be varying opinions on that. Maybe the way to
>>> approach
>>> this question is thinking about who could be editing the content.
>>> Should it
>>> always be technical individuals or should someone with writing skills be
>>> able to update the site as well?
>>>      
>> I'm not a current contributor to the python.org content, but I agree
>> with everything Skip said about this.  For people who are (python)
>> programmers, through-the-web editing is not agile.  ReST pretty much
>> *is* text.  The tools are not hard to learn...and perhaps demystifying
>> them for those who are scared of them would bring more developers into
>> the software community, which would be a great thing.  "Writers" can be
>> programmers too, some of them just don't know it :)
>>    
> Right - but it makes the *minimum* barrier for entry to contribute
> changes doing a full svn checkout, making changes in rest format (which
> I'm not proposing we drop as it goes) and then generating a patch (which
> then goes where?).
> 
> For a non-programming copy editor (for example) who wants to help this
> is a *huge* burden involving the command line and a whole bunch of
> tools. Absolutely no need for it to be this arcane. Just because they
> are tools that *we* as programmers are familiar with (and not all
> programmers are by any stretch of the imagination) is no reason to make
> it so complex.
> 
> There is also no conceptual reason that we couldn't come up with a
> system that allows both ways of working (a through the web system that
> generates patches for example) - but insisting we stick with the current
> system because we are familiar with it and have no reason to change is
> not good.
> 
+1
-- 
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/