Overview: main site redesign
Website team communication channels
- Subscribe to the www-team mailing list
- To post a message to all the list members, send email to
- To see the collection of prior postings to the list, visit the www-team Archives
#tor-wwwon OFTC (
All website tickets
How to contribute ideas
This wiki should be seen as a record of concrete proposals. As such, here is a loose procedure to follow if you would like to suggest new ideas:
- Write a proposal on the wiki
- Start a discussion on the www-team with a copy of the proposal
- Build a consensus and refine the wiki
The current website is powered by WML. Switching to a more recent engine supporting lighter syntax (like Markdown) is probably worthwhile.
- Content should be kept in Git.
- Support for the “Don't Repeat Yourself” principle, e.g. the latest version of the Tor Browser Bundle needs to be kept at a single place but used at different places in the website.
- Support translations. A changes in a single paragraph should be easily to propagate to translators and to then to translations.
The following projects look like potential candidates:
Pelican is a static site generator, written in Python. Documentation
Jekyll is a simple, blog-aware, static site generator, written in Ruby. Website
Middleman is a static site generator using all the shortcuts and tools in modern web development, written in Ruby. Website
Nikola is a Static Site and Blog Generator. Website
How to build the current website
Some commands than can be used on a Debian Wheezy system to build the current website:
apt install wml apt install --no-install-recommends asciidoc git clone https://git.torproject.org/tor.git git clone https://git.torproject.org/project/web/webwml echo "export TORGIT=$(pwd)/tor/.git" > webwml/Makefile.local cd webwml/ make
This should only be required if structural changes are necessary, typically you should push a branch with changes somewhere and ask for a pull by opening a ticket in the website component here.
Some notes from a discussion that happened during 30C3 gathering ideas on how to structure the website.
The following was brainstormed at the Berlin dev. meeting in September 2015.
Sebastian will be the main gatekeeper of the website. Changes should be proposed using tickets on Trac with the “website” component. Ideally the ticket should contain a pull request or a patch. For people who are not able to modify the code or don't want to, we have a team of people willing to act as integrator.
A “staging” website will be built automatically. When a substantial change is merged, a call for review should be sent to the www-team mailing list. A clear deadline for reviews should be announced in the call. Once that deadline is past and either there was not problems or they have been solved, the result is pushed in production.
For language changes, we might not want to push changes in production right away but rather gives a heads-up to translators. This would not be a blocker, but just a couple of days to give the chance to have more translations in sync.
To make a language available, the 85% of the website needs to be translated and the language should have a designated reviewer. That person would send pull requests once they have vouched a translation as correct. They would also be the point of contact when bugs are reported for a given translation.
Proposed new information architecture
- For: Everyone and journalists
- Tech Docs
- Outreach Materials Ideas Stuff
- Subproject - List
- Localized blog? E.g. fa-blog.torproject.org contains information specific to a given location. Do the same for de, mx, or other places?
The Student has recently heard about Tor and would like to discover more about it. Particularly he has heard from a friend that it could be used to protect his web browsing whilst using the university campus public wifi.
The Journalist has been writing about online privacy for the past year and would like to write a feature about Tor. Although she has previously experimented with Tor's browser bundle she would like further information of how the Tor infrastructure functions and the technical details behind how it enables online anonymity.
The Researcher works for a think tank. She has been a user of Tor since December 2011 and is a strong proponent for an open web. Since finding out about Tor, Stephanie has become involved in the Tor community contributing fixes and features to the Tor code base and engaging with other Tor contributers using the mailing lists and IRC.
The Donor has read about Tor in the local newspaper and would very much like to make a donation.
The Engineer has been a Tor Relay Operator for a little over a year and has encouraged two of his colleagues to do the same.
The Activist would like to comment anonymously on the Internet and not link her personal accounts to her activism work. She would like to use Tor to achieve this.
The Dissident lives under an oppressive regime which heavily filters the internet. He is very aware of the consequences to himself and his family if he is discovered. He is hesitant to use Tor without knowledge of how it works and what its limitations are (ie. an adversary that monitors Internet connections).
- Debian native citizen
- Static Site Generator
- Easy to use for whole staff
Useful base concepts
- Direct each user quickly to the right part
- If graphic redesign, think about the whole project, general 'CI'
- Communicate basic concepts with communication department
- Primary target: never deliver software without education
- Educate before download
- Educate on browser startup