Re: [Tails-project] About the 1.3 release notes

intrigeri:
> sajolida wrote (24 Feb 2015 18:27:29 GMT) :
>> Keyringer is meant to be used from the command line to share secrets
>> amongst different people (for example, we use it to store our
>> credentials as "Tails" for various websites). Whereas KeePassX is only
>> meant to be used by a single person. Keyringer is meant for a more
>> technical audience and that's why I initially put it in the second
>> section.
>
> I have to say I was quite surprised to see keyringer mentioned at all
> in these release notes, let alone as the fourth item. I thought the
> idea was to highlight the changes that most users had a chance to care
> about, which IMO isn't the case for a command-line utility (FTR, it
> was included only because it's needed when working on some Tails
> internal teams, otherwise I would probably have provided the standard
> "just use the additional software packages feature" answer ;)
>
> Not that I care *that* much, but I'd like to understand a bit better
> where the line is drawn, so that I can be better at providing bits of
> release notes for branches I submit :)

Clearly, the line is not drawn.

The history behind this is that I originally put it in the "Minor
changes" version (as I agree with your reasoning). But then the
blueprint was restructured in depth (probably by Diddly-Squat) who
renamed those sections into "New features" and "Upgrades and changes".
And so logically "keyringer" was included in the "New features".

I found that change between "major/minor" → "new/upgrade" interesting
and kept it like this. Maybe just to try it out.

Still I insisted to put keyring as the last item on that list and bring
back the Tor Browser confinement in this first section. So those two
examples might prove it hard to structure things like this.

But maybe Diddly-Squat can provide more rationale behind that change.
That would be interesting to here for me at least.

> As a minor side note, I'd like to point out that giving such CLI tools
> more exposure can add to our user support load. E.g. I've seen one
> person on #tails today asking for help about using keyringer.

Good news! This means that people do read the release notes.

> OTOH, for example I'm happy with seeing "Improved support for OpenPGP
> smartcards" mentioned in the 1.3 announce, on the grounds that
> reaching out to power-users is a good way to get more potential
> skilled contributors on board. So I'm not advocating for a "no CLI
> tool mentioned, ever" policy at all.

I think we need to talk to both less and more technically skilled people
in those notes. I tried to order each section according to the less
technical and wider audience first. But maybe I failed on some points.

>> It would be much easier for us, core developers, if the editing work was
>> done directly in the Git repository, on the development version of the
>> website. On the one hand, it would put the bar much higher for new
>> contributors to get involved, but on the other hand you would have all
>> the information you need about those new features. I don't really know
>> how to solve this. For example, would you be comfortable working in Git?
>
> My 2 bits: perhaps we'll need to have a built version of the testing
> branch online, some day. We could allow just specific blueprints to be
> edited online. Just a rough idea, probably not the best solution to
> the problem at hand.

I keep that proposal in mind.