Website team communication channels
- Subscribe to the www-team mailing list
- To post a message to all the list members, send email to email@example.com
- To see the collection of prior postings to the list, visit the www-team Archives
- #tor-www on OFTC (irc.oftc.net)
|#6851||Resume allowing website translations||Website||Tor Website 3.0|
Once upon a time, we let smart people check out the website svn, edit wml text files on their own, and provide translated versions of each page.
Then we decided to get smarter about it, and switch to various web-based approaches (like running our own pootle, or using other services like transifex). Our translators disappeared. Eventually Andrew deleted all the translations.
I talked to a lot of people the past few days (at the Berlin human rights conference) who were really sad that our website is English-only. We have tsum and try to maintain its translation, which is fine. But we have lots of other content that would be more useful in other languages.
What are the minimal steps to getting our website translations back up?
|#10022||We need a new blogging system||Blog|
The current blogging system is based on Drupal 5 and heavily hacked up to remove lots of surface area for classes of attacks. However, it doesn't work so much years later. The search functionality is broken. Lots of the admin functionality is broken as well. I've resorted to using raw SQL queries to manage the system. This is less than optimal.
Options I see are:
|#10591||Create a sitemap for current torproject.org website||Website||Tor Website 3.0|
Create a sitemap for current torproject.org website.
We need a current sitemap to let people understand our current information architecture.
|#11569||Consider making donations part of the download process||Website||Tor Website 3.0|
The re-designed download-easy page (https://www.torproject.org/download/download-easy.html.en) has resulted in a 2x increase in monthly donations since deployment. Some thoughts to consider:
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-get install wml 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.
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
How to contribute
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.