Re: [Tails-dev] The future of monthly reports, 2021 edition…

Poista viesti

Vastaa
Lähettäjä: syster
Päiväys:  
Vastaanottaja: The Tails public development discussion list
Aihe: Re: [Tails-dev] The future of monthly reports, 2021 edition [Was: Preparing the next monthly report]
Some inspiration for monthly reports can be the XMPP newsletter.
I've done more contribution (even not much) to Tails then to XMPP, but I never contributed to Tails monthly reports but to the one of XMPP.

some information about the XMPP report:

How to contribute is easy accessible: https://xmpp.org/newsletter.html
To contribute has an very easy entry point:
- there's a MUC specific for that, where you can just drop a line.
- there's a pad where you can add your contribution.
- there's git for final report

I don't know if there's something of value for Tails, since development and community in the XMPP ecosystem varies a lot from Tails (many independent projects using the same standard).



February 4, 2021 8:56 AM, "intrigeri" <intrigeri@???> wrote:

> Hi,
>



> Thanks for expressing your feelings and sharing your plans!
>
> Historical context
> ==================
>
> FWIW, here's what I remember from the last project-wide discussion on
> this topic:
>
> - Our starting point was that in the past, very few people were
> writing these reports. It was done from scratch, looking at Git
> history, changelog, Redmine, etc. This work was very tedious.
> At some point, the very few people who were doing this work wanted
> to stop.
>
> - We decided to make everybody responsible for writing their bits of
> report if they wanted, while the person assigned to a report "only"
> has to coordinate & curate it, so that:
>
> - Curating takes much less time, and is now feasible by many more
> community members (it does not require following All The Things
> anymore) ⇒ the curating workload can be spread more evenly.
>
> - The writing workload can be spread more evenly.
>
> Analysis
> ========
>
> Here's my analysis of how it went in practice wrt. our initial goals:
>
> - In terms of spreading the curating workload
>
> Apart of the aforementioned "very few people", a few community
> members took responsibility for curating reports:
>
> - 2020: 2 people (5 reports)
> - 2019: 3 people (5 reports)
> - 2018: 4 people (5 reports)
> - 2017: 3 people (6 reports)
>
> Thanks!
>
> I would say that on the "spreading the workload" aspect, this
> attempt has only been partly successful: on the one hand there's
> been more community involvement than in the past, which is great;
> but on the other hand more than half of our reports are still
> curated by the same 2-3 people, which is not sustainable at all,
> so we're back to square one.
>
> - In terms of writing bits of reports
>
> As far as I can tell, very few people have been writing bits of
> reports. There's a huge overlap between the set of people writing
> their bits of reports and the set of curators.
>
> Also, since these very few people, put together, are members of
> almost every Tails team, the contents has kept covering the vast
> majority of our work. On the one hand, it's good because it means
> our reports are not as incomplete as one may have feared. On the
> other hand, it means the attempt to spread the writing workload
> more evenly has totally failed.
>
> My conclusion is that overall, this new setup did not reach its goals:
> the work is less tedious for sure, but most of the work is still done
> by the same few people. In order to make this problem visible, I've
> also de-assigned myself from 2021 curator roles.
>
> And now?
> ========
>
> I still think these reports are very important in terms of "connecting
> with the rest of the world"¹, which matters in terms of relationships
> with our upstream & sibling projects, communication with our users,
> and in terms of fundraising. So I would be sad to see these reports
> stop for too long.
>
> I'm not up to trying yet another iteration of "everybody will do their
> bits and the workload will be shared", aka. the community magic dust.
> I need a more formal setup, that is sustainable without sajolida and
> myself, and with clear roles that reflect the importance of these
> reports to us.
>
> The first setup idea that I came up with:
>
> - technical writers act as writers and editors, i.e.:
>
> - use our internal team monthly reports to write good quality
> contents, with a communication style that's consistent with the
> rest of our communication (for example, shorter than this
> email :]]] )
>
> - define a strategy, e.g. in terms of frequency (it could be that
> monthly is not the best, I dunno, I'm not trained at this kind
> of communication)
>
> - welcome contributions from volunteers and decide what to do with
> them
>
> - other teams share info, needs, expectations, and feedback with
> technical writers about the intended audience they have in mind for
> these reports (e.g. FT about Debian & Tor people, fundraising about
> potential donors, etc.)
>
> At this point this is meant to be half a proposal, half a conversation
> trigger. Perhaps you disagree with my assumptions and goals?
> Perhaps you have other ideas?
>
> Also, this proposal is clearly not perfect. For example, in an
> organization with more resources, folks trained/experienced at
> communication would handle the communication strategy and act as
> editors. In our current situation, my impression is that technical
> writing is the closest skill we have in-house to communication, hence
> this proposal.
>
> Finally, I'm fine with either putting the reports on hold, or
> publishing them only when someone volunteered to curate them, until
> our technical writing capacity has increased sufficiently to cope with
> this additional task. I understand it is a matter of mere months
> now :)
>
> [1] Wrt. "communicating within the project" and "celebrating our
> achievements", IMO we now have better tools.
> _______________________________________________
> Tails-dev mailing list
> Tails-dev@???
> https://www.autistici.org/mailman/listinfo/tails-dev
> To unsubscribe from this list, send an empty email to Tails-dev-unsubscribe@???.