Commit e52c8a7a authored by anonym's avatar anonym
Browse files

Merge remote-tracking branch 'origin/master' into testing

Conflicts:
	wiki/src/contribute/release_process/test.mdwn
parents 04d9b112 f1b76806
[[!map pages="blueprint/SponsorS/*"]]
[[!meta title="Sponsor S reports"]]
[[!map pages="blueprint/SponsorS/reports/*"]]
[[!toc levels=2]]
<div class="caution">
<strong>Deadline: 2015-09-05</strong>
</div>
<div class="note">
Deliverable identifiers and descriptions are not free-form: they must
be copy'n'pasted as-is from the proposal sent to the sponsor.
</div>
# A. Replace Claws Mail with Icedove
## A.n. description of subsection
- A.n.m. description of deliverable: ticket numbers
status summary:
* what was done
* what is the outcome (how it makes Tails better)
* what was not done, and why
# B. Improve our quality assurance process
# C. Scale our infrastructure
# D. Migration to Debian Jessie
# E. Release management
[[!toc levels=2]]
<div class="caution">
<strong>Deadline: 2015-10-05</strong>
</div>
<div class="note">
Deliverable identifiers and descriptions are not free-form: they must
be copy'n'pasted as-is from the proposal sent to the sponsor.
</div>
# A. Replace Claws Mail with Icedove
## A.n. description of subsection
- A.n.m. description of deliverable: ticket numbers
status summary:
* what was done
* what is the outcome (how it makes Tails better)
* what was not done, and why
# B. Improve our quality assurance process
# C. Scale our infrastructure
# D. Migration to Debian Jessie
# E. Release management
[[!toc levels=2]]
<div class="caution">
<strong>Deadline: 2015-11-05</strong>
</div>
<div class="note">
Deliverable identifiers and descriptions are not free-form: they must
be copy'n'pasted as-is from the proposal sent to the sponsor.
</div>
# A. Replace Claws Mail with Icedove
## A.n. description of subsection
- A.n.m. description of deliverable: ticket numbers
status summary:
* what was done
* what is the outcome (how it makes Tails better)
* what was not done, and why
# B. Improve our quality assurance process
# C. Scale our infrastructure
# D. Migration to Debian Jessie
# E. Release management
[[!toc levels=2]]
<div class="caution">
<strong>Deadline: 2015-09-05</strong>
</div>
<div class="note">
Deliverable identifiers and descriptions are not free-form: they must
be copy'n'pasted as-is from the proposal sent to the sponsor.
</div>
# A. Replace Claws Mail with Icedove
## A.n. description of subsection
- A.n.m. description of deliverable: ticket numbers
status summary:
* what was done
* what is the outcome (how it makes Tails better)
* what was not done, and why
# B. Improve our quality assurance process
# C. Scale our infrastructure
# D. Migration to Debian Jessie
# E. Release management
[[!toc levels=2]]
<div class="caution">
<strong>Deadline: 2016-01-05</strong>
</div>
<div class="note">
Deliverable identifiers and descriptions are not free-form: they must
be copy'n'pasted as-is from the proposal sent to the sponsor.
</div>
# A. Replace Claws Mail with Icedove
## A.n. description of subsection
- A.n.m. description of deliverable: ticket numbers
status summary:
* what was done
* what is the outcome (how it makes Tails better)
* what was not done, and why
# B. Improve our quality assurance process
# C. Scale our infrastructure
# D. Migration to Debian Jessie
# E. Release management
[[!toc levels=2]]
<div class="caution">
<strong>Deadline: 2016-02-05</strong>
</div>
<div class="note">
Deliverable identifiers and descriptions are not free-form: they must
be copy'n'pasted as-is from the proposal sent to the sponsor.
</div>
# A. Replace Claws Mail with Icedove
## A.n. description of subsection
- A.n.m. description of deliverable: ticket numbers
status summary:
* what was done
* what is the outcome (how it makes Tails better)
* what was not done, and why
# B. Improve our quality assurance process
# C. Scale our infrastructure
# D. Migration to Debian Jessie
# E. Release management
[[!toc levels=2]]
<div class="caution">
<strong>Deadline: 2016-03-05</strong>
</div>
<div class="note">
Deliverable identifiers and descriptions are not free-form: they must
be copy'n'pasted as-is from the proposal sent to the sponsor.
</div>
# A. Replace Claws Mail with Icedove
## A.n. description of subsection
- A.n.m. description of deliverable: ticket numbers
status summary:
* what was done
* what is the outcome (how it makes Tails better)
* what was not done, and why
# B. Improve our quality assurance process
# C. Scale our infrastructure
# D. Migration to Debian Jessie
# E. Release management
[[!toc levels=2]]
<div class="caution">
<strong>Deadline: 2016-04-05</strong>
</div>
<div class="note">
Deliverable identifiers and descriptions are not free-form: they must
be copy'n'pasted as-is from the proposal sent to the sponsor.
</div>
# A. Replace Claws Mail with Icedove
## A.n. description of subsection
- A.n.m. description of deliverable: ticket numbers
status summary:
* what was done
* what is the outcome (how it makes Tails better)
* what was not done, and why
# B. Improve our quality assurance process
# C. Scale our infrastructure
# D. Migration to Debian Jessie
# E. Release management
[[!toc levels=2]]
<div class="caution">
<strong>Deadline: 2016-05-05</strong>
</div>
<div class="note">
Deliverable identifiers and descriptions are not free-form: they must
be copy'n'pasted as-is from the proposal sent to the sponsor.
</div>
# A. Replace Claws Mail with Icedove
## A.n. description of subsection
- A.n.m. description of deliverable: ticket numbers
status summary:
* what was done
* what is the outcome (how it makes Tails better)
* what was not done, and why
# B. Improve our quality assurance process
# C. Scale our infrastructure
# D. Migration to Debian Jessie
# E. Release management
[[!toc levels=2]]
<div class="caution">
<strong>Deadline: 2016-06-05</strong>
</div>
<div class="note">
Deliverable identifiers and descriptions are not free-form: they must
be copy'n'pasted as-is from the proposal sent to the sponsor.
</div>
# A. Replace Claws Mail with Icedove
## A.n. description of subsection
- A.n.m. description of deliverable: ticket numbers
status summary:
* what was done
* what is the outcome (how it makes Tails better)
* what was not done, and why
# B. Improve our quality assurance process
# C. Scale our infrastructure
# D. Migration to Debian Jessie
# E. Release management
[[!toc levels=2]]
<div class="caution">
<strong>Deadline: 2016-07-05</strong>
</div>
<div class="note">
Deliverable identifiers and descriptions are not free-form: they must
be copy'n'pasted as-is from the proposal sent to the sponsor.
</div>
# A. Replace Claws Mail with Icedove
## A.n. description of subsection
- A.n.m. description of deliverable: ticket numbers
status summary:
* what was done
* what is the outcome (how it makes Tails better)
* what was not done, and why
# B. Improve our quality assurance process
# C. Scale our infrastructure
# D. Migration to Debian Jessie
# E. Release management
[[!toc levels=2]]
<div class="caution">
<strong>Deadline: 2016-08-05</strong>
</div>
<div class="note">
Deliverable identifiers and descriptions are not free-form: they must
be copy'n'pasted as-is from the proposal sent to the sponsor.
</div>
# A. Replace Claws Mail with Icedove
## A.n. description of subsection
- A.n.m. description of deliverable: ticket numbers
status summary:
* what was done
* what is the outcome (how it makes Tails better)
* what was not done, and why
# B. Improve our quality assurance process
# C. Scale our infrastructure
# D. Migration to Debian Jessie
# E. Release management
Issues
======
Potential issues that might or might not have happened already.
From the developers point of view:
- Being told to do stuff without understand exactly why.
- Lack of synchronize between conception and development process. You
end up discovering UX issues too late.
- Cost-benefit ratio.
- Implementation starting too fast (lack of design) or, the other way
around, UX ideas bring in deep technical or security problems.
From the UX point of view:
- Developers are defensive (not important, not acknowledging the
problem).
- Lack of input from developers about technical feasibility, security,
maintenance, etc.
Fundraising and management point of view:
- Hard to prepare grant proposals without having input from both
sides.
- Hard to evaluate the time needed to implement changes. Sometimes you
know the problem already (sometimes not) but it's hard to know the
precise solution in advance.
- Hard to split responsibilities and for people to feel as working as
a team.
- UX tend to work more with big increments, involving user testing in
between while developers work with small increments and self or
automated testing so it might be hard for them to acknowledge the
need for more increments after their stuff works.
Different mind sets:
- Developer: you want something that works, that's a binary result.
- UX: you want something that is used.
- Difficult to make these two worlds communicate and agree on the
efficiency of a product.
TODO
====
- Improve our contribute section for developers to mention UX and
technical writing [[!tails_ticket 9926]]
- Ask feedback to the "other" side as soon as possible, or actually
better, work together from the beginning.
- Involve all actors in each grant proposal: designers, writers,
coders, sysadmins, etc.
- Find ways of involving developers in the UX process (user testing,
user feedback, etc.)
......@@ -22,31 +22,92 @@ We want to go from the inside to the outside, from the skeleton to the surface.
This is why, hereafter you will find a description of the logical order of steps. Of course, we can still work simultaneously on all of these steps, *but* it is useful to keep the whole roadmap in mind along the way.
2015
====
In 2015, we focused on [[Bootstrapping and upgrading workflow (granted)|blueprint/bootstrapping/]] and going on the the [[Greeter UI revamp|https://tails.boum.org/blueprint/greeter_revamp_UI/]].
Next
====
1. Inside
---------
- Greeter revamp (High) [[!tails_ticket 5464]]
- Network connection feedback [[!tails_ticket 7437]]
- MAT [[!tails_ticket 7684 ]]
- OTR [[!tails_ticket 7348 ]]
- OpenPGP Applet [[!tails_ticket 7778 ]] [[!tails_ticket 7450 ]]
- Shut down [[!tails_ticket 5417 ]]
* Change the language selection position in the Greeter [[!tails_ticket 9922]]
* Tor Monitor [[!tails_ticket 6842]]
* Graphical interface for additional packages persistence feature + improve the related boot delay [[!tails_ticket 9050]] & [[!tails_ticket 9059]]
* MAT [[!tails_ticket 7684]]
* Greeter revamp: phase 1 [[!tails_ticket 5464]]
* Tor and network progress bar [[!tails_ticket 7437]]
* Screen locker [[!tails_ticket 5684]]
* User-friendly backup system [[!tails_ticket 5301]]
* Localized clock [[!tails_ticket 6284]]
* Tails Installer on Mac OS X [[!tails_ticket 8559]]
* OpenPGP Applet [[!tails_ticket 7778 ]]
* Shut down [[!tails_ticket 5417 ]]
2. Installation
---------------
1. Refactor the installation documentation and add visual aids (installation screencast etc.)
A big work in done in 2015 to [[improve the installation workflow|blueprint/bootstrapping/]].
1. Refactor the installation documentation and add visual aids.
2. Automatic ISO verification [[!tails_ticket 7552]]
3. Multiplatform installer [[!tails_ticket 7544]]
In 2016, we want to go on:
* Tails Installer on Windows [[!tails_ticket 8550]]
* OpenPGP verification in Tails installer when ran in Debian [[!tails_ticket 9798]]
* Improve Tails Installer GUI [[!tails_ticket 8859]]
* Full self-upgrade [[!tails_ticket 7499]]
3. Website
----------
- Re-define the goals of the website and maybe split it in differents sections [[!tails_ticket 7627]]
- work on accessibility
### Content and structure
There are 2 two dimensions of work we have to do :
#### Content
Re-define the goals of the website and maybe split it in differents sections [[!tails_ticket 7627]]
For example :
* A - new commers (infographic, videos, homepage, tails identity) [[!tails_ticket 9814]]
* B - power users
* C - dev / contributors
#### Structure (html and css)
Modernize the html and css structure.
* D - "fanciness"
* E - responsiveness
* F - accessibility
### Website roadmap
Depending on grants and availibilities, here are the big steps we could do:
- late 2015 : review the CSS and HTML from the Installation Assistant [[!tails_ticket #9915]]
- early 2016 : maybe migrate the layout of the website following the work on the Installation Assistant css and html (E, F)
- mid 2016 : starts working on new commers issues (generic Tails presentation). Think and unify meaning and graphical identity (we could make a survey to gather information). (A)
- 2017 : work on other sections of the website (B,C)
4. Outreach
-----------
- Promote Tails outside of the website, regarding the differents people and use cases where Tails could be usefull.
- 2018 : Promote Tails outside of the website, regarding the differents people and use cases where Tails could be usefull.
......@@ -7,7 +7,7 @@
Rationale
=========
tails-greeter works fine, and its code in not that bad anymore, so on
Tails-greeter works fine, and its code in not that bad anymore, so on
this side it's now feasible to add features (e.g. [[!tails_ticket
5421]], [[!tails_ticket 5479]]).
......@@ -21,28 +21,29 @@ easier to use.
Current proposal
================
After working on a prototype and do UX testing with Numa people, we arrived to
the idea of two main flows:
After working on a prototype and doing UX testing with NUMA [[http://en.numa.paris/]], we arrived at the idea of having two main Tails-greeter flows:
- a quick setup for regular users;
- a wizard to guide newcomers
- a quick setup for veteran users
- a guided setup for new users
The result of this step can be found in [[NUMA_flow]].
The result of this can be found in the [[NUMA_flow]].
We refined this on the *tails-ux* mailing list to arrive to a concrete proposal
for the 1st screen.
We refined this on the *tails-ux* mailing list to arrive at a concrete proposal for the first screen.
Mockup: [[https://mailman.boum.org/pipermail/tails-ux/attachments/20150729/b774d708/attachment-0001.png]]
**TODO** write here a summary of the decisions and of the flow of the greeter,
including what happens when some parameters are saves.
Rationale: [[https://mailman.boum.org/pipermail/tails-ux/attachments/20150806/811ba063/attachment.pdf]]
**COMING SOON!** A summary of the proposed Greeter flow and what happens when some parameters are saved.
Flow: [[#]]
Next steps
==========
Roadmap:
* document design of the 1st screen and ask for comments.
* finish documenting design of the 1st screen and ask for comments.
* implement UI in glade and integrate into the greeter
* design the wizard
......
......@@ -170,9 +170,16 @@ ___
___
./doc/about/tor --DONE, not pushed