Re: [Tails-project] May report

Supprimer ce message

Répondre à ce message
Auteur: sajolida
Date:  
À: Public mailing list about the Tails project
Sujet: Re: [Tails-project] May report
intrigeri:
> 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 top of translation, let's not forget writing. I like writing the same
stuff twice. Another option would be to copy-pasting stuff from the
release notes.

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


I suspect those people read the release notes as well and might prefer
not reading the same stuff twice either (changes that have been released
already). On the other hand it makes more sense to tell them about the
changes that are going to be released as they can react on them before
they are released or get excited about future stuff.

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


As you said, the value of both the release notes and reports is to
summarize and communicate to the outside world tons of little things
that otherwise happen on internal channels (Redmine, mailing lists).
So it's not duplicating them as such, it's summarizing and rephrasing
them for a different audience. And unless we find a rationale to
summarize and rephrase stuff differently in the report than in the
release notes, we're doing the same work twice and sending it to pretty
much the same audience. Against, maybe copy-pasting is the way to go.

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


Yes.

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


I've done that in commits 49e1c00 and 883757d. Please have a look. And
feel free to bring back the work that was done for 1.4 in May from the
release notes into the release section of the report.

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


Ah, that's good as well. I already separated stuff for 1.4 and 1.5
before reading again your email. Feel free to merge them to simplify.

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


--
sajolida