Re: (low-frequency) mailing lists | suggestions & summary of prior thread

[Albert Astals Cid]

El dimarts, 23 de maig de 2023, a les 14:10:37 (CEST), Joseph P. De Veaugh-
Geiss va escriure:
> Follow-up discussion to the post "Inactive mailing lists".
> 
> tl;dr There are three topics discussed here:
> 
>1. For mailing list admins: *Suggestions For Information To Add To
> Mailing List Descriptions*
>2. For mailing list communities: *Moving Certain Groups To Discourse?*
>3. For everyone: *Summary Of Prior Discussion About Inactive /
> Infrequently Used Lists*
> 
> As always, the discussion is open for your feedback and ideas!
> 
> _1. Information To Add To Mailing List Descriptions_
> 
> If you are a list admin, consider adding the following to the mailing
> list description. This way subscribers are well-informed about the
> communication channels used for your project/community:
> 
>* Other communication channels for this project and their intended
> use (e.g., for announcements, user support, live chat, etc.)
>* Relevant links for the project (e.g., website, wiki, etc.)
>* Intended scope for the list (i.e., what it is for / not for)
>* Policies regarding moderation, code of conduct, etc.
> 
> For examples, see:
> 
>* Energy-efficiency:
> https://mail.kde.org/cgi-bin/mailman/listinfo/energy-efficiency
>* Kde-soc: https://mail.kde.org/mailman/listinfo/kde-soc
>* Visual-design: https://mail.kde.org/mailman/listinfo/visual-design
> 
> _2. Moving Certain Groups To Discourse?_
> 
> Beyond typical forum functionality, Discourse integrates well with email
> and RSS. Something to consider for low-frequency mailing list groups:
> there may be projects and communities that benefit by officially moving
> communication to Discourse. Although I have no data to back up the
> claim, I suspect having users interact on a more active platform could
> generally increase engagement within KDE.
> 
> A nice feature of Discourse is: for mailing list subscribers who wish to
> continue receiving posts in their mail clients,

Is it really? I remember once that i visited, commented on a post and never 
ever got emails when people answered me on that post. I am not a crazy person 
that plans visiting discuss.kde.org every 5 minutes just in case someone has 
answered me, the site must send me an email and in my 1 time experience it 
failed to do so.

Cheers,
  Albert

> it is possible to follow
> discussions via RSS or by enable mailing list mode in Discourse. It
> takes some setting up; see below for more.
> 
> A few language and country-specific communities already have made a move
> to Discourse. See:
> 
> https://discuss.kde.org/c/local-communities/
> 
> Some of these groups also have low traffic mailing lists. Unless current
> list subscribers also move to Discourse, there is the risk of fracturing
> the community as list subscribers are seperated from the people at the
> forum. In this case, archiving and closing the infrequently-used mailing
> list might be beneficial. Of course, that is for the list admin and
> relevant community to decide.
> 
> Info about using Discourse with email and RSS:
> 
>* Users can enable "Mailing list mode", which allows one to receive
> and respond to posts via email (i.e., just like a mailing list). By
> default, users receive posts to /all/ categories -- limiting posts to
> specific categories requires manually "muting" the other categories. See
> the community wiki for more detail, including how to mute categories:
> 
>  https://community.kde.org/KDE.org/KDE_Forums#Mailing_List_Mode
> 
>* Alternatively, one can follow specific categories, tags, etc. as an
> RSS feed. Again, see the community wiki for details:
> 
>  https://community.kde.org/KDE.org/KDE_Forums#Following_RSS_Feeds
> 
> _3. Summary: Prior Discussion About Inactive Mailing Lists_
> 
> Here are some bullet points from the discussion about inactive /
> infrequently used mailing lists. For the full thread, go to:
> 
> https://mail.kde.org/pipermail/kde-community/2023q2/007577.html
> 
>* Some lists deliberately have archiving disabled, so an empty
> archive is not necessarily an indicator of no activity.
>* Some lists are primarily used for following bug reports (e.g.,
> *-bugs) or commits.
>* Subscribing to a low traffic email list is rarely something people
> notice, and the UI of mail clients rarely gets in the way. By contrast,
> the UI of e.g. Matrix very much gets in the way of staying in 200 low
> traffic channels.
>* Low email traffic does not mean subscribers will not answer
> appropriate posts sent to it.
>* Unless current subscribers also make the move to a new channel,
> moving discussion to a new platform risks separating the people who have
> answers (the current subscribed people) with the people who have the
> questions (the people redirected elsewhere).
>* For lists that are unquestionably no longer in use, please file a
> sysadmin ticket and they will get removed.
>* See this ticket for mailing lists that have been or 

Re: (low-frequency) mailing lists | suggestions & summary of prior thread

[Stefan Derkits]

Hi,

On 23/05/2023 14:10, Joseph P. De Veaugh-Geiss wrote:
   * See this ticket for mailing lists that have been or will be removed 
as a result of the discussion: https://phabricator.kde.org/T16387


it seems that the visibility of this Phabricator Task is very limited, 
e.g. I can't view it, it says: "You Shall Not Pass: Restricted Maniphest 
Task"


Can you open up the visibility of the task a bit more?

Stefan


OpenPGP_signature
Description: OpenPGP digital signature

(low-frequency) mailing lists | suggestions & summary of prior thread

[Joseph P. De Veaugh-Geiss]

Follow-up discussion to the post "Inactive mailing lists".

tl;dr There are three topics discussed here:

  1. For mailing list admins: *Suggestions For Information To Add To 
Mailing List Descriptions*

  2. For mailing list communities: *Moving Certain Groups To Discourse?*
  3. For everyone: *Summary Of Prior Discussion About Inactive / 
Infrequently Used Lists*


As always, the discussion is open for your feedback and ideas!

_1. Information To Add To Mailing List Descriptions_

If you are a list admin, consider adding the following to the mailing 
list description. This way subscribers are well-informed about the 
communication channels used for your project/community:


  * Other communication channels for this project and their intended 
use (e.g., for announcements, user support, live chat, etc.)

  * Relevant links for the project (e.g., website, wiki, etc.)
  * Intended scope for the list (i.e., what it is for / not for)
  * Policies regarding moderation, code of conduct, etc.

For examples, see:

  * Energy-efficiency: 
https://mail.kde.org/cgi-bin/mailman/listinfo/energy-efficiency

  * Kde-soc: https://mail.kde.org/mailman/listinfo/kde-soc
  * Visual-design: https://mail.kde.org/mailman/listinfo/visual-design

_2. Moving Certain Groups To Discourse?_

Beyond typical forum functionality, Discourse integrates well with email 
and RSS. Something to consider for low-frequency mailing list groups: 
there may be projects and communities that benefit by officially moving 
communication to Discourse. Although I have no data to back up the 
claim, I suspect having users interact on a more active platform could 
generally increase engagement within KDE.


A nice feature of Discourse is: for mailing list subscribers who wish to 
continue receiving posts in their mail clients, it is possible to follow 
discussions via RSS or by enable mailing list mode in Discourse. It 
takes some setting up; see below for more.


A few language and country-specific communities already have made a move 
to Discourse. See:


   https://discuss.kde.org/c/local-communities/

Some of these groups also have low traffic mailing lists. Unless current 
list subscribers also move to Discourse, there is the risk of fracturing 
the community as list subscribers are seperated from the people at the 
forum. In this case, archiving and closing the infrequently-used mailing 
list might be beneficial. Of course, that is for the list admin and 
relevant community to decide.


Info about using Discourse with email and RSS:

  * Users can enable "Mailing list mode", which allows one to receive 
and respond to posts via email (i.e., just like a mailing list). By 
default, users receive posts to /all/ categories -- limiting posts to 
specific categories requires manually "muting" the other categories. See 
the community wiki for more detail, including how to mute categories:


https://community.kde.org/KDE.org/KDE_Forums#Mailing_List_Mode

  * Alternatively, one can follow specific categories, tags, etc. as an 
RSS feed. Again, see the community wiki for details:


https://community.kde.org/KDE.org/KDE_Forums#Following_RSS_Feeds

_3. Summary: Prior Discussion About Inactive Mailing Lists_

Here are some bullet points from the discussion about inactive / 
infrequently used mailing lists. For the full thread, go to:


   https://mail.kde.org/pipermail/kde-community/2023q2/007577.html

  * Some lists deliberately have archiving disabled, so an empty 
archive is not necessarily an indicator of no activity.
  * Some lists are primarily used for following bug reports (e.g., 
*-bugs) or commits.
  * Subscribing to a low traffic email list is rarely something people 
notice, and the UI of mail clients rarely gets in the way. By contrast, 
the UI of e.g. Matrix very much gets in the way of staying in 200 low 
traffic channels.
  * Low email traffic does not mean subscribers will not answer 
appropriate posts sent to it.
  * Unless current subscribers also make the move to a new channel, 
moving discussion to a new platform risks separating the people who have 
answers (the current subscribed people) with the people who have the 
questions (the people redirected elsewhere).
  * For lists that are unquestionably no longer in use, please file a 
sysadmin ticket and they will get removed.
  * See this ticket for mailing lists that have been or will be removed 
as a result of the discussion: https://phabricator.kde.org/T16387


Cheers,
Joseph

--
Joseph P. De Veaugh-Geiss
KDE Internal Communications & KDE Eco Community Manager
OpenPGP: 8FC5 4178 DC44 AD55 08E7 DF57 453E 5746 59A6 C06F
Matrix: @joseph:kde.org

Generally available Monday-Thursday from 10-16h CET/CEST. Outside of 
these times it may take a little longer for me to respond.


KDE Eco: Building Energy-Efficient Free Software!
Website: https://eco.kde.org
Mastodon: @be4foss@floss.social

Re: Retiring Phabricator - Migrating tasks to Gitlab

[Ben Cooksley]

On Tue, May 23, 2023 at 11:39 AM Nate Graham  wrote:

> Great, this will be a good thing to have behind us.
>

You can say that again.

Phabricator is a bit of a nightmare to host - in large part because the
entire content of our Subversion repository is indexed in it's database,
which has resulted in it consuming ~400GB on disk.
Along with it being unmaintained, i'll be very happy to archive it and
shutdown that container.


> Because workboards in GitLab are Label-driven via automation, I think we
> would have to make each workboard column in Phabricator transform into a
> custom label in GitLab so that Tasks' positions in workboards can be
> preserved when they move to GitLab.
>

This aligns with what Johnny has mentioned and seems reasonable enough to
me.
In theory it shouldn't be too hard to automate.


>
> Also, in Phabricator, Tasks have no real "home"; they just have project
> tags, and they can have multiple such tags to be able to belong to
> multiple projects. For example "VDG" and also "Plasma". Such a Task
> shows up in both projects' workboards. But in GitLab, Issues need to
> live in one place and only one place. So for such Phab tasks, we would
> need a way to determine the single new home of the Task in GitLab, and
> perhaps tag them with global-scope labels or something?
>

Yes, we would need to do a deconflicting process there.
Any thoughts on the best approach to that?

The simplest would be to consider some projects to be the natural "home"
for tasks (likely the app in question) while meta groups (such as VDG /
Windows / Flatpak / etc) would only get a task if it was the only project
on a task.


>
> In Gitlab, it's Labels all the way down...
>

Yes :)


>
> Nate
>

Cheers,
Ben


>
>
> On 5/21/23 03:14, Ben Cooksley wrote:
> > Hi all,
> >
> > As many of you will undoubtedly be aware, we currently have a bit of a
> > hybrid approach with our use of GitLab, with some projects/areas still
> > making use of Phabricator as they await the final import of these tasks
> > across to GitLab.
> >
> > That time has now arrived, as Phabricator is long since unmaintained and
> > needs to be retired.
> >
> > The only question is how this is best structured.
> >
> > My thinking on this had been to establish a mapping of Phabricator
> > project to Gitlab project (with some Gitlab projects possibly receiving
> > multiple Phabricator projects). Where necessary we would create
> > groups/projects under teams/ on invent.kde.org 
> > to house these, otherwise they'd be imported into the mainline projects.
> >
> > For those projects currently using GitLab as a task tracking tool, any
> > feedback you have on this would also be welcome.
> >
> > In terms of the migration, we'd be looking to retain as much information
> > as possible, however things like the precise column a task has on a
> > workboard would likely be lost. The actual content of the task including
> > details such as time and authorship, along with any comments would be
> > retained though.
> >
> > Thoughts?
> >
> > Thanks,
> > Ben
>