Request for Proposal

Summary

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.

Proposal guidelines

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:

  • An overview of your company’s recommended process for the project
  • A draft timeline with staggered deliverables for the project. (We envision the redesign requiring 3 to 6 months to build.)
  • Sketches of potential layouts which express the team’s vision for python.org are extremely helpful in proposal selection, but are not required for submission.
  • Your suggestions for each of the points identified in Purpose, below.
  • Your qualifications for the areas identified in Scope, below.

Proposals must contain the following information about the proposer:

  • Company name, contact information and website URL
  • Background, including company history, team members, services
  • Which company resources would be dedicated to the project
  • Samples and designer portfolios of work similar in size and scope
  • Contact information for references.

Purpose

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:

  • Boast a modern design and experience
  • Provide concise and intuitive navigation
  • Showcase the simplicity and elegance of the language
  • Attract and convert potential Python users and Python Software Foundation sponsors
  • Represent the vibrant, active community
  • Make it easy for a wide range of contributors to add content
  • Enhance the visibility of the PSF and its sponsors
  • Provide examples of success stories
  • Enhance the visibility of alternate implementations (Jython, IronPython, PyPy...)
  • Exist atop stable and scalable infrastructure (99.99% availability; able to survive a slashdotting).

Scope

The scope of the project work will encompass the primary web site, python.org. There are four main areas that should be focused on:

  • Information architecture
  • Visual design and user experience
  • Front- and back-end development
  • System architecture and monitoring

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.

Requirements

Note

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.

Optional requirements:

  • May support a workflow to allow content to be vetted before publication.
  • May support a sub-site staging area where proposed subsites could be developed, only going public after approval by the overall site administrators.

Migration of Existing Data

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.

Licensing

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.

Audiences

Potential users

These users are new to Python or investigating it for potential use. Questions they may have include:

  • What is Python?
  • What does it look like (e.g. syntax)?
  • Why would I want to use Python?
  • How do I get started with Python?
  • How do I learn Python?
  • Who uses Python (success stories)?
  • How do I communicate with other Python users?
  • What are some ways Python is being used today?
  • Who is using Python for XYZ industry?

Existing users

These users already use and/or contribute to Python. Examples of information they are trying to gather include:

  • How do I do XYZ with Python?
  • How do I become a Python expert?
  • Where are the closest Python user groups?
  • Which developers in my area are using Python?
  • How do I find a Python job?
  • Is our company’s version of Python current?
  • What sources of information are there on XYZ in Python?
  • What is the roadmap for Python?
  • How do I donate to support Python?
  • How do I download the current release of Python?
  • How do I download an older release of Python?
  • How do I tell if this is a bug in my code or in Python?
  • How do I submit a bug report?
  • How do I become a contributor?
  • How do I write or contribute to the documentation for Python?

Users of other languages

These users primarily use other programming languages. Examples of what these users may be asking include:

  • Why should I switch to Python?
  • Can I use Python in tandem with the language(s) I’m using today?
  • How does Python compare to language XYZ?
  • Does Python have an implementation of a tool that exists in my language?
  • Does Python have an implementation of a tool that does not exist in my language?

Managers

These users may be technical or non-technical. Examples of what these users may be looking for include:

  • Who uses Python? Why?
  • What are some ways others are using Python?
  • Why does my staff insist on moving to Python?
  • How high is the quality of the software?
  • Python is popular. Should we be using it?

Contributors

These users are heavily vested in Python and contribute to the language. They may be asking:

  • Who is working on which features for the next release?
  • When is build XYZ due?
  • What show-stopper bugs should I focus on?
  • What easy bugs are available to work on?
  • How do I contribute [code|bug reports]

Sponsors

These are potential contributors / sponsor members for the Python software foundation, the information they would be looking for includes:

  • All information in the “Managers” section
  • Information about the Python Software Foundation including what it is has done, current projects, and how to join.
  • What benefits sponsorship includes.

Current Issues

Architecture and Maintenance

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.

Information Architecture

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/.

Visual Design

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 new design should follow current best practices for web design, such as using valid HTML, using CSS instead of tables, following accessibility guidelines, degrading gracefully if the user’s browser does not run JavaScript, etc.

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.

Project Management

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.

Cost/Price Estimates

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:

  • Back-end work: $(fixed amount)
  • UI/UX: $(amount per iteration/hour) up to $(max)
  • Ongoing stuff: $(amount)/month

Selection process

Proposals will be evaluated based on the following criteria:

  • Proposal timeliness.
  • Did the submitter follow the submission instructions?
  • Was the proposal comprehensive?
  • Did the proposal cover the five main points mentioned in scope?
  • Are the resources, experience and technical expertise of the company adequate?
  • Is there a clear plan for follow-up and further requirements discussions and refinement?

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: