DS:
Hi DS, thanks a lot for your contribution!
> I was uncertain if you wanted a link to the project management area.
> But, it’s public info, correct?
> And there really are more changes than
> were listed in the original version of the release notes, so I figured
> the technically oriented may want to know.
Not really, because what's on Redmine will keep on changing and getting
flagged differently so the link that you added won't work once the
release is over. On top of that, we put quite a lot of stuff there that
is not digest for users (even the more technical ones).
What we usually do is to point to the Changelog (which has been redacted
by the release manager). So I did that. We're now pointing to
https://git-tails.immerda.ch/tails/plain/debian/changelog. Note that the
Changelog itself refers to the Redmine ticket in the project management
area as you call it.
Maybe the confusion arose because on the blueprint I only put the part
of the release notes related to actual changes, and not the whole
template that we are using usually (with the link to the Changelog,
Known issues, Download, etc.).
> 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. Still, there are no equivalent of keyringer with a user
interface as far as we know.
> I’m unsure of the intent of the link to learning more (“Learn more about
> how to manipulate files with Tor Browser). Why do I want to learn more?
We expect the new security feature of the browser to confuse many
people. You won't be able to download to or upload files from any folder
on the file system but only download to or upload from dedicated
folders. That's why I felt the need to explain this quite prominently in
the release notes.
See the part on "AppArmor confinement" on
https://git-tails.immerda.ch/tails/tree/wiki/src/doc/anonymous_internet/Tor_Browser.mdwn?h=testing
> Also, I don't see anything in this link about files or folders which is
> the change we’re talking about. I assume that will be changed . . .?
Right. The thing is that the blueprint that you worked on was in the
production version of our website. But the documentation it was pointing
to was not released yet and was only existing in our Git repository.
That's why the internal links were broken: they were pointing to
something that was not existing yet!
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?
> I regards to the Mac and Linux installation processes no longer
> requiring the isohybrid command. I assume the command will be removed
> from the Mac and Linux instruction pages, which if done, really makes
> this addition to release notes somewhat unnecessary.
Right. Still people might be used to do that mechanically instead of
following the instructions step-by-step each time. But you might know
better than me what's to expect in such cases.
> In regards to the Pidgin configuring info. I don’t understand the
> purpose. It is a mandatory change on the user’s part? Is it a security
> issue? It needs to be stated why people should, or under what conditions
> people should make this change.
Me neither :) I inherited this from anonym, but then we realized that it
was not needed. Better!
> I think all good release notes need to include known issues, so I
> provided the link to them.
Yes, those were in our usual template. I now glued everything together.
The current state of things is here:
https://git-tails.immerda.ch/tails/tree/wiki/src/news/version_1.3.mdwn?h=testing
> Oh, I noticed the hyperlinks were using wiki markup. I used the actual
> URL only because it was readily apparent to me how to do that.
Sure, and I totally understand why that was easier for you and I fixed
them. But there are several issues with using full URLs:
- They won't work in the offline version of the documentation that's
included in Tails. That might not be a big deal for the release notes
but we really want to provide hypertext offline documentation.
- I'm not sure they work well with translated pages (or actually) not
translated pages pointing to translated pages. I think with full URLs
pointing to .en.html, I would be redirected to the English version of
the website even if I'm browsing the Portuguese version.
If you want to continue contributing to the content of the website like
this, it's definitely worth giving a try at building a local version of
the wiki on your system. I can explain you how to do that if you work
from Tails for example. That would make it more comfortable for you as
well to be able to work in a proper text editor and not in a web form.
