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

Hi,

Sorry to be late for the party, I wasn't available back when my input
would possibly have been more useful. This email is meant to
participate in building a common understanding of what should go into
the release notes, and what should not.

sajolida wrote (24 Feb 2015 18:27:29 GMT) :
> DS:
>> I really don't understand what the Keyringer program does? Does it
>> replace KeyPassX? Why would people need it or use it?

> 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 :)

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.

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'm not really happy with this process as I understand that it doesn't
> make such for you for example to work on release notes when you haven't
> seen to actually documentation of the new features.

> 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.

Cheers!
--
intrigeri