... | ... | @@ -2,30 +2,20 @@ |
|
|
|
|
|
**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.
|
|
|
* 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.”
|
|
|
* 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)
|
... | ... | @@ -34,89 +24,77 @@ than “assess customer service satisfaction.” |
|
|
* 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.**
|
|
|
|
|
|
`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)
|
|
|
* 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
|
|
|
|
|
|
* 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
|
|
|
* 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
|
|
|
* 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
|
|
|
|
|
|
* 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.
|
|
|
|
|
|
|
|
|
* 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
|
|
|
|
|
|
* 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
|
|
|
|
... | ... | @@ -124,44 +102,43 @@ than “assess customer service satisfaction.” |
|
|
|
|
|
###### 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
|
|
|
* 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
|
|
|
|
|
|
* 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 |
|
|
* 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 |
|
|
\ No newline at end of file |