Re: [Tails-project] May report

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: Public mailing list about the Tails project
Subject: Re: [Tails-project] May report
Hi,

sajolida wrote (02 Jun 2015 10:36:30 GMT) :
>> Code and Infra are only drafted, there are probably more to add.


> I'd rather not duplicate what we already have written in release notes
> and rather link to them.


I'm a bit torn on this one. On the one hand, I realize that
duplication is always a potential problem (in particular for
translatable content, which is the case here). On the other hand:

* one of the reasons why these reports are very useful is the fact
they are self-contained => anyone who reads them, and doesn't read
anything else, gets a good overview of what's going on in Tails
world without having to click through more links. I'm thinking e.g.
of LWN and tor-reports@ readers: it would feel strange to me if
reading the report gave them details about all Tails activities...
except actual "code" changes;

* one could argue that 90% of what's in our reports is duplicate
information that's already available somewhere else anyway, just in
a digested, summed up and rephrased form, so taken in isolation,
the duplication argument is a bit weak to fully convince me.

> I'm also wondering whether we should mention code changes that will be
> mentioned in future release notes.


After reading the following paragraphs, my understanding is that you
mean something like "whether we should make it clear what code changes
are for a future release", rather than whether we should mention those
changes altogether. Please correct me if I got it wrong :)

> Our monthly reports are aimed at two
> different public:


> - Our users base, then those people might wonder whether such changes
> are ready to use or not.
> - Our Tails and Tor colleagues, then those people might comment on a
> change before it's released. If so, then what about having a section
> about "preparing 1.4.1 (for example)" and listing what's relevant in
> there. We used to list such things in the past without mentioning that
> they were *future* changes and didn't like it so much. I'll try to have
> a look before we publish the report, but maybe it's not relevant this time.


+ people who follow the project from a slightly more remote
perspective, of which I gave examples above.

> Does it make sense to you?


Yay, seems like a very good idea!

One way to do it would be to move past releases' changes (if we keep
them) into the "Releases" section, and add an introduction sentence to
the "Code" section that clarifies that it's about future releases.

Also, just a nit: I don't think it's necessary to go as far as
mentioning which exact release each change is scheduled for. Instead,
I would point to the relevant ticket, and those who are *really*
interested in that topic will see up-to-date target version
info there.


And, regarding the current report itself: I've proofread it and pushed
some fixes. Will now check if I have stuff to add. You may consider
that I'm done (or that I failed) at the end of the week.

Cheers,
--
intrigeri