|
|
# [Objectives and Key Results](https://en.wikipedia.org/wiki/OKR)
|
|
|
|
|
|
**It is a goal setting framework used by individuals, teams, and organizations to define measurable goals and track their outcomes.**
|
|
|
|
|
|
|
|
|
#### [Tips for setting objectives](https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/):
|
|
|
|
|
|
* Pick just three to five objectives - more can lead to over-extended
|
|
|
teams and a diffusion of effort.
|
|
|
* Avoid expressions that don’t push for new achievements, e.g., “keep
|
|
|
hiring,” “maintain market position,” “continue doing X.”
|
|
|
* Use expressions that convey endpoints and states, e.g., “climb the
|
|
|
mountain,” “eat 5 pies,” “ship feature Y.”
|
|
|
* Use tangible, objective, and unambiguous terms. It should be obvious
|
|
|
to an observer whether or not an objective has been achieved. Research
|
|
|
shows more specific goals can result in higher performance and goal
|
|
|
attainment.
|
|
|
|
|
|
#### Tips for developing key results:
|
|
|
|
|
|
* Determine around three key results per objective.
|
|
|
* Key results express measurable milestones which, if achieved, will directly advance the objective.
|
|
|
* Key results should describe outcomes, not activities. If the KRs include words like “consult,” “help,” “analyze,” “participate,” they’re
|
|
|
describing activities. Instead, describe the impact of these activities, e.g., “publish customer service satisfaction levels by March 7th” rather
|
|
|
than “assess customer service satisfaction.”
|
|
|
* Measurable milestones should include evidence of completion and this evidence should be available, credible, and easily discoverable.
|
|
|
|
|
|
|
|
|
### Goals at the Tor Project
|
|
|
|
|
|
* coverage (list of goals for every team lead or area lead)
|
|
|
* document work attached to each goals
|
|
|
* implement a routine to review goals and work associated
|
|
|
* teams do it every 3 months
|
|
|
* team leads or area leads have goals per semester
|
|
|
|
|
|
|
|
|
### Objectives per team and area
|
|
|
|
|
|
**TODO: OKRs for the teams have too many objectives.**
|
|
|
**TODO: how we measure the advancement of the goals?**
|
|
|
**TODO: we need OKRs per semester.**
|
|
|
|
|
|
|
|
|
#### Network product lead
|
|
|
|
|
|
- usable networks that is safe and secure
|
|
|
- enumerate barriers/difficulties with use of Tor network
|
|
|
- enumerate, document, prioritize major network problems related to usability and security
|
|
|
- use okr methods to describe problem and solution options (personas, stories, product briefs, design criteria)
|
|
|
|
|
|
##### Responsibilities
|
|
|
|
|
|
- identify and gather usage and sec problems wrt varios Tor user personas
|
|
|
- use usability and competitive analysis to inform prioritization of problems
|
|
|
- work with key stakeholders to determan potential solution to problems
|
|
|
- ensure potential solutions have req, design criteria, stories and success metrics
|
|
|
- track status of solutions and ensure they progress through R&D pipeline and end up in funding proposals and roadmaps
|
|
|
|
|
|
|
|
|
##### July to December 2021
|
|
|
|
|
|
- improve network performance
|
|
|
key results: implementation of congestion control in next tor release
|
|
|
|
|
|
- use okr methods to describe problem and solution options (personas, stories, product briefs, design criteria)
|
|
|
key results: get all the other goals organized in okrs
|
|
|
|
|
|
#### Chief of Network Health and Anti-Censorship
|
|
|
|
|
|
- Websites, ISPs, companies, and countries should *value* Tor.
|
|
|
- They should understand the benefits of letting users reach the Tor network and of letting Tor users reach the rest of the Internet.
|
|
|
- The Tor network should operate smoothly, and we should understand its dynamics
|
|
|
- Have visibility into how the network is operating
|
|
|
- Be good at recognizing anomalies (overload, attack, censorship, bugs, networking problems)
|
|
|
- Have a large and diverse community of relay/bridge operators
|
|
|
- Operators should be informed and confident about the value of their contributions, and be clear on how they can increase their contributions
|
|
|
- Have an automated process for recognizing and mitigating bad relays/bridges
|
|
|
- Understand the spectrum of what it means to trust a relay/bridge; make sure we have enough good ones
|
|
|
- Tor Browser should work (not too much network censorship/interference) out of the box in most countries
|
|
|
- It should be easy for users to learn how to get Tor, and configure it properly, for whatever censorship they are facing
|
|
|
|
|
|
##### Responsibilities
|
|
|
|
|
|
- Mentor Georg and Cecylia in their roles as team leads, and help keep the roadmaps on-vision for each team
|
|
|
- Provide org-wide continuity and historical context about Tor and the Tor network, e.g. so we don’t forget what we’ve tried before
|
|
|
- Ensure that we value our relay/bridge operators
|
|
|
- Recognize, assess, escalate issues inside the Tor network or protocol that allow attacks that degrade the network
|
|
|
- Recognize and escalate existential threats to Tor / network
|
|
|
Raising the alarm about websites blocking Tor users some of the for-profit Tor relay designs shifts in public opinion that make Tor dangerous to use internet centralization trends
|
|
|
- Advocate for changes to Tor and Tor Browser that will make users safer from attacks. E.g. “https always" on by default, removing v2 onions.
|
|
|
Make sure we understand which countries are blocking Tor and how they’re doing it
|
|
|
- Figure out how to get better at reacting to new events so we can assess new censorship quickly
|
|
|
- Maintain awareness of what Pluggable Transports are needed in every country
|
|
|
- Make sure we have a pipeline for keeping Tor Browser supplied with working Pluggable Transports
|
|
|
- Coordinate with [Mike’s role] on steps to improve the health and performance and security of the network as a whole
|
|
|
- Maintain relationships with funders/partners/major donors
|
|
|
- Grant manager / PI for RACE: coordinate reports, work with partners to set roadmaps, present progress to funder, negotiate timeframes, make sure we meet expectations, shield other Tor people from it
|
|
|
- Be an ambassador to tough audiences: advocate and explain Tor and privacy to groups that fear it but are too important for us to ignore
|
|
|
- Facilitate Tor network research: make sure we have processes for coordinating network experiments in a safe and transparent way
|
|
|
- Advocate for (with the community team) maintaining strong connections to relay/bridge operators, especially to the relay operator non-profits, and providing ways for them to build community
|
|
|
|
|
|
|
|
|
#### Chief architect / software planner
|
|
|
|
|
|
- Our software should be intelligible,maintainable, & reliable.
|
|
|
|
|
|
|
|
|
|
|
|
#### UX Team: human-centered design
|
|
|
|
|
|
##### July to December 2021
|
|
|
|
|
|
- define the mvp for our new client
|
|
|
- develop better feedback cycles
|
|
|
- provide a strong foundation for the UX team
|
|
|
- streamline our design processes and handoffs
|
|
|
- engage and grow the Tor UX community
|
|
|
|
|
|
|
|
|
#### Applications Team: browsers, vpn, integration and unblock tor
|
|
|
|
|
|
##### July to December 2021
|
|
|
|
|
|
###### for the browser
|
|
|
|
|
|
- hire new software engineer
|
|
|
- android tor browser release on schedule
|
|
|
- android/linux tb automated tests are passing
|
|
|
- release 11.0 on schedule
|
|
|
- being surveying the browser ecosystem
|
|
|
|
|
|
###### for the vpn
|
|
|
|
|
|
- hire new software engineer
|
|
|
- begin the design
|
|
|
- integration
|
|
|
- create easy to use arti api
|
|
|
- document required components for android app integration
|
|
|
- begin discussing android components ownership with gp
|
|
|
- unblock tor
|
|
|
- create partnerships with friendly web services
|
|
|
- create working group with partners
|
|
|
|
|
|
|
|
|
#### Anti-censorship Team: develop, investigate, research circumvention technologies
|
|
|
|
|
|
##### July to December 2021
|
|
|
|
|
|
- make Tor accessible in China
|
|
|
- detect and categorize attempts to censor Tor
|
|
|
- improve the design and reliability of our software
|
|
|
- release our data and software for use by the broader anti-censorship community
|
|
|
- improve the performance of Snowflake so that Tor bootstraps reliably on a mobile phone in China
|
|
|
- deploy TapDance and Conjure as high collateral damage PT
|
|
|
- commit to a design for a reputation-based bridge distrubtion system
|
|
|
- streamline our private bridge setup and distribution process
|
|
|
- deploy probes in areas that are likely to censor Tor and collect pack captures and probe results for storage and analysis
|
|
|
- provide OONI with suggestions for iproving the accuracy of OONI's Tor tests
|
|
|
- summarize the details of Tor blocking events with data from our probes and volunteers
|
|
|
- add more user metrics based monitoring and alert rules using prometheus
|
|
|
- deploy rdsys ad the new backend of bridgedb
|
|
|
- ensure that key infrastructure can survive machine outages and restarts
|
|
|
- remove hacky shims necessary for moat
|
|
|
- future improve the snowflake library api to allow easy integration of snowflake with other tools
|
|
|
- sanitize, publish and archive the results of our Tor reachability probes
|
|
|
- complete our documentation for each of our tools so that other organizations can run their own anti-censorship infrastructure |