[pydotorg-www] project plan

Jesse Noller jnoller at gmail.com
Thu Apr 22 04:46:25 CEST 2010



On Apr 21, 2010, at 10:04 PM, Steve Holden <steve at holdenweb.com> wrote:

> Jesse Noller wrote:
>> On Wed, Apr 21, 2010 at 9:08 PM,  <skip at pobox.com> wrote:
>>>   Michael> Just because they are tools that *we* as programmers are
>>>   Michael> familiar with (and not all programmers are by any  
>>> stretch of
>>>   Michael> the imagination) is no reason to make it so complex.
>>>
>>> But change for the (apparent) sake of change seems wrong to me.  I  
>>> have yet
>>> to see a concrete proposal for what you would use to replace the  
>>> current
>>> technology or who the potential users of the current technology  
>>> are who have
>>> been unable to surmount the current barriers.
>>
>> There is no proposal because Rich is evaluating the requirements of
>> such a tool Skip. We are discussing the various use cases, users,
>> consumers and creators. A proposal and project plan will be  
>> developed.
>> We are only in the discussion/requirements planning phase.
>>
>>>   Michael> There is also no conceptual reason that we couldn't  
>>> come up
>>>   Michael> with a system that allows both ways of working (a  
>>> through the
>>>   Michael> web system that generates patches for example) - but  
>>> insisting
>>>   Michael> we stick with the current system because we are  
>>> familiar with
>>>   Michael> it and have no reason to change is not good.
>>>
>>> That would seem to fall into the "if it ain't broke, don't fix it"
>>> category.
>>
>> We've always been at war with Eurasia.
>>
>>> I suspect that the initial impetus for this effort was that the  
>>> website
>>> content needs significant rework.  For the time being at least I  
>>> think it
>>> would be best to focus on the new/revised content and structure  
>>> and leave
>>> the tools as-is.  I'll grant that the current tools used to  
>>> maintain the
>>> website aren't for everyone, but they work for the people who  
>>> currently
>>> twiddle the bits and they will get the job done without requiring  
>>> a big
>>> investment in developing new tools or adapting other off-the-shelf  
>>> tools to
>>> handle our specific needs.  The last time the site was redesigned  
>>> Tim
>>> Parking spent a large amount of time developing a new tool set,  
>>> then a
>>> couple years later Andrew Kuchling reworked them to get them to  
>>> the state
>>> they are in today.
>>
>> Just because things "sorta work" right now, for "a select subset of
>> the technologically elite" (of which, all of us discussing us are  
>> part
>> of) does not mean the system is Good or Complete. The goal, as I
>> understand (and have been encouraging on the PSF list and elsewhere)
>> is to examine the current state of tools, and content and not only do
>> a redesign of the look and feel of the site itself, but also improve
>> the tool chain to reduce the friction of contribution.
>>
>> As a piece of anecdotal evidence - I speak to people *daily*, in  
>> which
>> the conversation goes like this:
>>
>> Them: "Man, I found a bug in the docs/python lib/site"
>> Me: "Please file a bug, better yet, file a patch! Especially the  
>> docs,
>> they're easy to fix!"
>> Them: <rummaging>
>> Them: I have to do *what* to change a line in the docs?! Check out
>> code? Do a diff? Screw that!! I have other things to do that *pay  
>> me*.
>> Me: Please file a bug at least!
>> Them: Why bother? It's going to take forever for it to get fixed. You
>> deal with it.
>>
>> Daily. I have these conversations *daily*. It is a firm, and total
>> belief of mine that almost anyone using, documenting, testing with,  
>> or
>> writing tools for/in python today can become an active contributor to
>> Python as a whole - no matter how insignificant the contribution is.
>>
>> In order to help that belief though; I'm firmly in the camp which is
>> asking we modernize the tool chain - offer a web-based
>> comment/feedback tool ala the Django Book, a CMS for the
>> less-programming-inclined to add content (and correct it, or even to
>> auto-submit patches). Using mercurial for patch/code management, etc.
>>
>> This is not a matter of killing the contributors that have gotten us
>> this far; it's about bringing in more people by lowering the barrier,
>> friction, and time it takes to become a *contributing* member.
>>
>> As I understand the current undertaking which spurred this discussion
>> - this is a requirements and feedback gathering project, which will
>> beget RFPs/Proposals which the PSF itself will fund or guide the
>> development of. I don't think having modern tools, a modern look and
>> feel, cleaner layout and organization is bad in any way.
>
> I understand Skip's desire to bring some existing content up to date
> without waiting for the "grand plan", but surely if what he says is  
> true
> then the only thing stopping it happening is the difficulty of  
> making it
> happen? I'm certainly not saying that we can't edit the current  
> content.
> In fact I'd be happy to see it edited.
>
> I believe that there are large pools of untapped resources, which  
> would
> include the people you quote above. I also believe there are high
> barriers to entry, some of which are social and some of which are
> technical. I think that lowering the technical barriers might also  
> allow
> us to loosen some of the social barriers. "Empowerment" is what's
> needed. People like Skip need to know that they can just go and edit  
> the
> site as they want, without asking for permission.
>
> The ability to revert undesired changes would clearly be valuable, but
> in Skip's case is unlikely to be required.
>

I think we violently agree.


More information about the pydotorg-www mailing list