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" <intrig...@boum.org> 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@boum.org > https://www.autistici.org/mailman/listinfo/tails-dev > To unsubscribe from this list, send an empty email to > tails-dev-unsubscr...@boum.org. _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://www.autistici.org/mailman/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
