Python.org Redesign DocumentationRelease 1

Jesse Noller

November 28, 2012

CONTENTS

i

ii

CHAPTER

ONE

SUMMARY

The Python Software Foundation (PSF) is accepting proposals for architecture, design, development, and maintenanceof 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 anddeployed in Spring 2006. The site is currently maintained by a team of community volunteers using a custom suite oftools. To get a better understanding of the current system, you can review the redesign proposal, slideshow and systemusage 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 informationabout it. This (welcome) abundance of information has outgrown the current website’s taxonomy. The key goal of thisproject is to update Python’s official web presence with an eye to better organizing the information we have today (andexpect to add in the future). The end result should aid the various audience roles in locating the information relevantto their needs.

1

Python.org Redesign Documentation, Release 1

2 Chapter 1. Summary

CHAPTER

TWO

PROPOSAL GUIDELINES

Proposals should be submitted by 11:59pm EST, 07/21/2012 via email to psf-redesign in PDF format. Proposalsreceived after this date and time will not be considered. Proposals should be comprehensive, covering all aspects ofthis 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 signatoryto the contract. We encourage teams and individuals to collaborate on this project as we feel it will enrich the finalproduct 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 conflictof 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 monthsto build.)

• Sketches of potential layouts which express the team’s vision for python.org are extremely helpful in pro-posal 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.

3

Python.org Redesign Documentation, Release 1

4 Chapter 2. Proposal guidelines

CHAPTER

THREE

PURPOSE

Although the current implementation of the Python web site has served its purpose over the years, the time has comefor the site to progress and complement the growth and maturity of the language itself as well as the vibrancy of thecommunity.

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

5

Python.org Redesign Documentation, Release 1

6 Chapter 3. Purpose

CHAPTER

FOUR

SCOPE

The scope of the project work will encompass the primary web site, python.org. There are four main areas thatshould 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:

• http://python.org/

• http://python.org/community/

• http://python.org/download/

• http://python.org/news/

• http://python.org/psf/

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 andapplications (e.g. planet.python.org) at a later date.

7

Python.org Redesign Documentation, Release 1

8 Chapter 4. Scope

CHAPTER

FIVE

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 byboth 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 documentto 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 thehome page that links to Spanish documentation.

• Ability to quickly create sub-sites (e.g. edu.python.org, mentors.python.org, etc.) A sub-site mightcontain some HTML pages of content, some images and PDF files, and a weblog; sub-sites are not full-blownweb 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 initiallaunch, but the process must be clear.

• Section 508 compliance (possibly WAI-ARIA compliance). The site should comply with the spirit of the guide-lines, but need not be 100% compliant with the letter of the law. (100% compliance is not mandated in order toavoid 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 supportedby 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 DOMload/document ready) of less than 3 seconds, with no outliers beyond 10 seconds.

9

Python.org Redesign Documentation, Release 1

• Monitoring of critical systems using modern monitoring tools, such as Munin, etc. Bidders should coordinatewith 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 ap-proval by the overall site administrators.

5.1 Migration of Existing Data

All content from the existing site must be migrated to the new system. Content of historical pages must not bemodified, although they should be restyled to fit the new appearance.

5.2 Licensing

All content, code, visual design, imagery and other related work for the site must be done with a licensing scheme thatallows 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 permissivelicensing 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 approvedlicenses. Bidders may use proprietary software for their own internal purposes (e.g., checking site compatibility withclosed 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. Forexample, a proposal can use Chef, which is written in Ruby; a proposal cannot use Drupal, which is written in PHP,for everything.

10 Chapter 5. Requirements

CHAPTER

SIX

AUDIENCES

6.1 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?

6.2 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?

11

Python.org Redesign Documentation, Release 1

• 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?

6.3 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?

6.4 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?

6.5 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]

6.6 Sponsors

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

• All information in the “Managers” section

12 Chapter 6. Audiences

Python.org Redesign Documentation, Release 1

• Information about the Python Software Foundation including what it is has done, current projects, and how tojoin.

• What benefits sponsorship includes.

6.6. Sponsors 13

Python.org Redesign Documentation, Release 1

14 Chapter 6. Audiences

CHAPTER

SEVEN

CURRENT ISSUES

7.1 Architecture and Maintenance

Currently the site uses a custom-built content build system - this system requires technical knowledge (e.g. of Subver-sion and Make) to add the smallest news item to the system. We need the ability for individuals with limited codingexperience 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 workfor less technical people and a more browser/forms-based approach is wanted by a certain fraction of expected sitecontributors, this RFP calls for APIs to manipulate the site content for supporting online and offline work as well ascontent 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 forinstalling the system, and user documentation for the workflows to edit/add/publish content. Developers or contentauthors 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; thewinner(s) of the bid may provide assistance, but does not carry the primary burden of supporting the system.

7.2 Information Architecture

If you examine the current home page, you will note the amount of information first presented to the user is over-whelming, 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 confus-ing/disjointed. In addition, many sections of the site have overlapping use cases, so a strictly hierarchical navigationmakes 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 possiblePython resource. Today’s search engines are better and there are many relevant web sites, so the architecture may dropsome of the current content and promote different material. For example, do we want to discard the News or “UsingPython 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/.

7.3 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 andunorganized fashion. The visual elements and cues used are inconsistent and disorganized.

15

Python.org Redesign Documentation, Release 1

The new design should follow current best practices for web design, such as using valid HTML, using CSS instead oftables, 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 thedesign 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.

16 Chapter 7. Current Issues

CHAPTER

EIGHT

PROJECT MANAGEMENT

Contact information for primary and secondary contacts for the proposing team should be be provided. Proposalsshould 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.

17

Python.org Redesign Documentation, Release 1

18 Chapter 8. Project Management

CHAPTER

NINE

COST/PRICE ESTIMATES

We understand that the design and architecture (UI/UX) part is likely to be a number of rounds of back and forthbetween the designer/architect person and the PSF. We understand that it is impossible to put a fixed budget on adesign 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 thefollowing format:

• Back-end work: $(fixed amount)

• UI/UX: $(amount per iteration/hour) up to $(max)

• Ongoing stuff: $(amount)/month

19

Python.org Redesign Documentation, Release 1

20 Chapter 9. Cost/Price Estimates

CHAPTER

TEN

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 forall inquiries should be psf-redesign. Bidders should feel free to ask questions of the current maintainers or discusstheir proposal before final submission by posting to pydotorg-www.

Additionally, if needed you can contact:

• Andrew Kuchling, PSF Board member: amk@python.org

• Python Software Foundation board: psf@python.org

21