From jnoller at gmail.com  Wed Jun 13 19:44:49 2012
From: jnoller at gmail.com (Jesse Noller)
Date: Wed, 13 Jun 2012 13:44:49 -0400
Subject: [PSF-Volunteers] [PSF-Members] RFP: Redesign python.org
In-Reply-To: <63E20027-788E-47F6-95C8-71BECABB10E9@gmail.com>
References: <20120523205624.GA28415@cpl10cishanson.coxinc.com>
	<D1169C8C7CBC4D11B792BBA077D1FBB7@gmail.com>
	<63E20027-788E-47F6-95C8-71BECABB10E9@gmail.com>
Message-ID: <EE034979A21744DDBE7B4704DC5B2656@gmail.com>

Please send questions to psf-redesign at python.org, especially if you are working on a proposal. 


On Wednesday, June 13, 2012 at 1:25 PM, Massimo Di Pierro wrote:

> Hello Jesse,
> 
> I have some questions about the redesign of python.org (http://python.org) and I am not 
> sure where to ask. I will ask here but please forward as appropriate.
> 
> I see the following url patterns:
> 
> http://python.org/3kpoll
> http://python.org/_sources
> http://python.org/about
> http://python.org/community
> http://python.org/communitydiversity
> http://python.org/dev
> http://python.org/diversity
> http://python.org/doc
> http://python.org/donations
> http://python.org/emacs
> http://python.org/files
> http://python.org/forms
> http://python.org/fraud
> http://python.org/getit
> http://python.org/grants
> http://python.org/idle
> http://python.org/league
> http://python.org/links
> http://python.org/members
> http://python.org/membership
> http://python.org/news
> http://python.org/psf
> http://python.org/psfabout
> http://python.org/psfdonations
> http://python.org/psffraud
> http://python.org/psfleague
> http://python.org/psfsponsorship
> http://python.org/pycon
> http://python.org/python-mode
> http://python.org/records
> http://python.org/review
> http://python.org/search
> http://python.org/source
> http://python.org/sponsorship
> http://python.org/topics
> http://python.org/windows
> http://python.org/winring
> http://python.org/wirexfer
> 
> Which of them should NOT be covered by the proposal?
> 
> Some of them can be treated as wiki/cms pages but some seem to have 
> more structured information. For example polls and community jobs. You 
> stress that the pages should be editable offline, that prevents the 
> implementation of a web based workflow for posting and for commenting 
> on job announcements. The same goes for memberships, voting, polling, 
> proposing a pep, commenting on a pep. etc.
> 
> Should the proposal include any type of web based workflow other than 
> trivial edit -> approve -> publish?
> If so which information should be subject to the workflow? Should a 
> description of the workflow be part of the proposal or the existing 
> workflow already documented?
> 
> About content that should be editable offline. Let's consider an 
> hypothetical scenario of a github repository of static media files and 
> rst files, plus a web app that converts the rst to html pages allows 
> editing of the html and publishes the final result. This raises some 
> issues:
> 
> - It is possible that an offline edit conflicts with an online edit. 
> How do you want to deal with merge? Do you want to deal with merge 
> from the shell offline or should the web interface be able to do diff 
> and merge?
> - Can one assume that all the content, including under development 
> content is public? If not this excludes a github-like option. Should 
> there be read permissions associated to each individual page.
> 
> About design. Is there a preference for a more artistic design or a 
> more sober one (like twitter's bootstrap)?
> 
> About tools. Are there libraries and tools that are a priori 
> recommended or not recommended other than restructuredtext (rst)? what 
> about non-pythonic tools like pandoc?
> 
> The proposal mentions the ability to easily create sub-domains. That 
> involves DNS and Web server configuration. Should the proposal include 
> tools and workflow to automate the editing of the DNS and web server 
> config files? In this case are there any guidelines about which web 
> server is recommended?
> 
> Massimo