Re: [Tails-project] Restructuring our support page

Delete this message

Reply to this message
Author: sajolida
Date:  
To: Public mailing list about the Tails project, Cody Brownstein
Old-Topics: Re: [Tails-project] Restructuring our support page
Subject: Re: [Tails-project] Restructuring our support page
NB: I'm putting Cody in copy again.

Cody: I see that you're not subscribed to tails-project@???. I
think you should :)

intrigeri:
> sajolida:
>> We brainstormed on this with Cody today and came up with a plan to
>> improve things.
>
> I like your plan. I'll comment inline below.


Thanks for the feedback, I'm glad you like it :)

>> Move "Report an error" as a option to contact us
>
> I don't understand this sentence.


Right now we have three purple headings:

1. Report an error            2. Request a feature


3. Get in touch with us

Our proposal is to advertise "Report an error" as a way of contacting us
(by email)...

>> Could we go even further and say that people who cannot start Tails
>> should write us an email and people who can start Tails should send
>> us a WhisperBack report?
>
> Sounds good.


... which goes in that direction.

>> Do we really want to advertise the chat that much?
>
> Probably not. There's very little happening there. Very few users with
> a good understanding of Tails help others. Most core Tails people
> connect either rarely or never.


Adding this to the blueprint. Removing this as an option would be much
simpler for us :)

>> Do we want to make it less visible until it's easy to connect and
>> get answers?
>
> Yes.


I updated the blueprint.

>> Is the chat helpful for people who can't start Tails?
>> They would have to install XMPP!
>
> In my experience, questions about problems with starting Tails are
> indeed rare there.


It make sense.

>> Create a page dedicated to issues starting Tails and link it from
>> wiki/src/support.mdwn
>
> … and link it from doc/first_steps/bug_reporting too I guess?


Sure. I admit that we didn't really look at
/doc/first_steps/bug_reporting but it will probably be affected by our
plans.

>> Inline issues from latest release
>
> We did try to inline inc/stable_*_release_notes at some point but then
> we had to revert it due to ikiwiki bugs (#9564, #6907). I suspect that
> this part of your plan would reintroduce exactly the same kind of bugs
> e.g. on /news. IMO it's not merely an implementation detail, but
> rather a matter of taking into account the limitations of our tools
> while designing.


We could also copy the content instead of using inlines:

- I could prepare the replacement of the old list in the branch where I
write the release notes. We have a good process for that so it's not
going to be forgotten.
- We could have a comment in the release notes template to remind us to
update the copy whenever we update this section after the release,
which happens quite often.

It would be a bit more painful for translators, but less painful than
having broken inlines. Worse case, the copies are a bit out of sync
during a release cycle. If we detect that it will be easy to sync the
copies.

Now I'll go ask explicitly our help desk to comment on this as they are
the ones dealing with people in trouble.