The Python Software Foundation (PSF) is accepting proposals for architecture, design, development, and maintenance of the primary web site for the Python programming language, www.python.org.
The existing Python web site was originally discussed at PyCon 2003. The site was then designed, developed and deployed in Spring 2006. The site is currently maintained by a team of community volunteers using a custom suite of tools. To get a better understanding of the current system, you can review the redesign proposal, slideshow and system usage guide by checking out the following code through subversion:
svn co https://svn.python.org/www/trunk/beta.python.org/resources/docs/ beta-python-docs
Python has grown significantly in the last few years, both in terms of audience and the amount of topical information about it. This (welcome) abundance of information has outgrown the current website’s taxonomy. The key goal of this project is to update Python’s official web presence with an eye to better organizing the information we have today (and expect to add in the future). The end result should aid the various audience roles in locating the information relevant to their needs.
Proposals should be submitted by 11:59pm EST, 07/21/2012 via email to psf-redesign in PDF format. Proposals received after this date and time will not be considered. Proposals should be comprehensive, covering all aspects of this RFP. The PSF will then take up to three months to review all the received proposals before making a decision.
Note: Bids submitted by a collaborative team of professionals are acceptable as long as there is a single signatory to the contract. We encourage teams and individuals to collaborate on this project as we feel it will enrich the final product and reflects the Python community’s ethos.
Officers and Directors of the Python Software Foundation can be part of a proposal team, but must declare their conflict of interest and recuse themselves from the final selection.
Proposals should include:
Proposals must contain the following information about the proposer:
Although the current implementation of the Python web site has served its purpose over the years, the time has come for the site to progress and complement the growth and maturity of the language itself as well as the vibrancy of the community.
This project represents an opportunity to revamp the Python web site from the ground up.
The next implementation of the site should:
The scope of the project work will encompass the primary web site, python.org. There are four main areas that should be focused on:
Examples of URLs that will be included in this project are:
The scope does not include sub-domains of python.org such as pypi.python.org or bugs.python.org. However, the work performed should be done in such a way that the brand can be applied to other PSF properties and applications (e.g. planet.python.org) at a later date.
These requirements are hard requirements, and are non-negotiable in any proposal.
Content must be editable offline, when there is no network availability. Content may additionally be editable by both in-browser and external command line tools.
Multiple versions of content must be saved as edits are made, with a facility for reverting an individual document to an older version.
Permit the use of reStructuredText for content markup.
Allow for easy localization of content and URLs. For example, we might present a Spanish translation of the home page that links to Spanish documentation.
Ability to quickly create sub-sites (e.g. edu.python.org, mentors.python.org, etc.) A sub-site might contain some HTML pages of content, some images and PDF files, and a weblog; sub-sites are not full-blown web applications like Roundup or Drupal.
Ability to quickly create blogs (e.g. python.org/blogs/psf)
Aggregate and incorporate content from various sources (e.g. blip.tv, blogs, news feeds, etc.)
Detailed plan for importing all existing site content. This conversion does not need to be complete for an initial launch, but the process must be clear.
Section 508 compliance (possibly WAI-ARIA compliance). The site should comply with the spirit of the guidelines, but need not be 100% compliant with the letter of the law. (100% compliance is not mandated in order to avoid the need for a full audit by an expert.)
A well-documented (REST) API for retrieval and creation of content, with preference given to APIs supported by existing client-side tools such as common offline editing/blogging tools.
Open and standards-based accessible APIs that can be used from any language.
These APIs/tools should also be documented on the website itself. e.g. if a piece of content requires Mercurial, the page should contain simple instructions such as:
Get a local copy of the FOOBAR repository with this command: hg clone https://blah-blah-blah
Provide 301 redirects for those URLs that change (or retain current URLs).
Ability to add new 301 redirects in case the information architecture changes.
Fast page speed/aggressive caching. The target is an average front-end page load time (e.g. time until DOM load/document ready) of less than 3 seconds, with no outliers beyond 10 seconds.
Monitoring of critical systems using modern monitoring tools, such as Munin, etc. Bidders should coordinate with the PSF Infrastructure team on tool selection.
Must run on PSF servers; must not be locked to a single cloud hosting company’s infrastructure of tools.
All content from the existing site must be migrated to the new system. Content of historical pages must not be modified, although they should be restyled to fit the new appearance.
All content, code, visual design, imagery and other related work for the site must be done with a licensing scheme that allows for the Python Software Foundation to redistribute, relicense and otherwise disseminate the material.
The Foundation requires that the construction of the system respect the principles behind Python’s own permissive licensing scheme and open source software in general. The required toolchain to build, operate and maintain the site, including all code deployed as part of the site itself, must consist entirely of open source software under OSI approved licenses. Bidders may use proprietary software for their own internal purposes (e.g., checking site compatibility with closed source web browsers), but use of such tools must not be essential to working effectively with the system.
The primary implementation language must be Python, though components in other languages can be used. For example, a proposal can use Chef, which is written in Ruby; a proposal cannot use Drupal, which is written in PHP, for everything.
These users are new to Python or investigating it for potential use. Questions they may have include:
These users already use and/or contribute to Python. Examples of information they are trying to gather include:
These users primarily use other programming languages. Examples of what these users may be asking include:
These users may be technical or non-technical. Examples of what these users may be looking for include:
These users are heavily vested in Python and contribute to the language. They may be asking:
These are potential contributors / sponsor members for the Python software foundation, the information they would be looking for includes:
Currently the site uses a custom-built content build system - this system requires technical knowledge (e.g. of Subversion and Make) to add the smallest news item to the system. We need the ability for individuals with limited coding experience to contribute and maintain content on the main site and sub-sites.
We envision the new system as a markup-based document system that supports offline contribution. (http://www.readthedocs.org is a example of this approach.) Since the existing markup/offline approach doesn’t work for less technical people and a more browser/forms-based approach is wanted by a certain fraction of expected site contributors, this RFP calls for APIs to manipulate the site content for supporting online and offline work as well as content federation and other uses. Details of how to achieve this are left to the creativity of the bidder.
The system must also be well-documented, providing an overview describing the general architecture, instructions for installing the system, and user documentation for the workflows to edit/add/publish content. Developers or content authors may wish to run the application locally for their own purposes, so the system must be installable for them.
Post-launch, we envision that PSF volunteers will perform most future improvements and maintenance tasks; the winner(s) of the bid may provide assistance, but does not carry the primary burden of supporting the system.
If you examine the current home page, you will note the amount of information first presented to the user is overwhelming, and the navigation on the left hand side is as well. The latter - either through lack of organization or “informational spread” of information (the site has grown organically over time) - means that navigation is confusing/disjointed. In addition, many sections of the site have overlapping use cases, so a strictly hierarchical navigation makes material difficult to find.
The current site contains a lot of content because at one time the goal was to contain or at least link to every possible Python resource. Today’s search engines are better and there are many relevant web sites, so the architecture may drop some of the current content and promote different material. For example, do we want to discard the News or “Using Python For” sections from the home page? Vendors may wish to look at web sites for other programming languages, including but not limited to http://www.perl.org, http://www.ruby-lang.org/, http://www.haskell.org/.
The current visual design is felt to be very dated, and lacking many of the new UX and UI attributes (cleanliness, color, etc) that represent the modern web. The site does present a massive amount of information - in an overwhelming and unorganized fashion. The visual elements and cues used are inconsistent and disorganized.
The proposal must not feature a redesign of the Python logo. The new design may feature the logo prominently or the design may omit it, but the logo cannot be changed.
The proposal may feature a retheming of http://docs.python.org but need not do so.
Contact information for primary and secondary contacts for the proposing team should be be provided. Proposals should include descriptions of the project management processes and tools typically used by the proposal organization. After a proposal is accepted, the PSF will expect weekly status reports.
We understand that the design and architecture (UI/UX) part is likely to be a number of rounds of back and forth between the designer/architect person and the PSF. We understand that it is impossible to put a fixed budget on a design process since by its very nature it should be iterative and back-and-forth.
Therefore, quotes should be broken down to reflect appropriate rates instead of a single fixed-price estimate, in the following format:
Proposals will be evaluated based on the following criteria:
Final selection will be made by the Python Software Foundation board of directors. The primary point of contact for all inquiries should be psf-redesign. Bidders should feel free to ask questions of the current maintainers or discuss their proposal before final submission by posting to pydotorg-www.
Additionally, if needed you can contact: