Managing list offtopicness better.

newer
Nathan Wolf's link in Helios might...

older
[opensuse-project] mailing lists:...

Simon Lees

12 Dec 2020 12 Dec '20

00:11

Hi All, The board has noticed an again increasing amount of offtopic discussion on both the Project and Factory mailing lists, including some users having longer then needed conversations drawn out over a significant number of emails per thread. Our new mailing list setup has given us some more options with regards to this. In particular the board has decided that users who regularly take the list off topic from now will be placed under moderation for a period of time. To help facilitate this the board has asked the mailing list admin's to create a mailing list moderation team with enough people to reasonably cover all timezones, once this team is created it should be able to become self sustaining like the forum moderators for example. If you are passionate about this and believe you would be a good candidate feel free to contact the mailing list admins at admin@o.o as I believe they are looking for a couple more candidates especially in European timezones. As a reminder the project mailing list is for non technical project wide / community wide discussions. The factory list is strictly for development discussions, with a reminder that we have the support list and forums for user support, the user list for general discussion and an offtopic list for everything else. There are also many other lists for specific topics and languages you can find a link to them all below, the link below that covers all the other places you can interact with the community https://lists.opensuse.org/archives/ https://en.opensuse.org/openSUSE:Communication_channels -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Attachments:

OpenPGP_signature.sig (application/pgp-signature — 495 bytes)

Show replies by date

Per Jessen

12 Dec 12 Dec

13:23

Simon Lees wrote:

...

To help facilitate this the board has asked the mailing list admin's to create a mailing list moderation team with enough people to reasonably cover all timezones,

Just in case there was a miscommunication - I am one of the list admins, and I have not been asked for anything like that, nor would I have agreed to it. Stasiek asked if I was okay with the idea, to which I (in summary) said I saw no problem in it, but that it was way overkill. -- Per Jessen, Zürich (5.4°C) Member, openSUSE Heroes

Adrien Glauser

13:55

There are few clear-cut and objective criteria for on-topic vs. off-topic. Putting people under moderation on the base of unclear, non-objective criteria might not the best of ideas if you want to build trust and healthy social interactions. Arbitrariness and biases will probably be lurking in about every corner. Fortunately the on / off -topic is not the most relevant distinction you need to keep the MLs clean. If you need a middle-ground between (dangerously arbitrary, free-speech infringing) moderation and nice but sometimes insufficient abstract rules (such as the Code of Conduct), you can do 2 simple things: 1) Provide a clear path / resolution site for interpersonal conflicts and issues. For example if two people are going two far, you take them apart and iron things out, taming the fire before it spreads over other channels. 1 able person might suffice for doing that for not just the mailing lists but every oS channel. So that instead of punishing, you might end up creating a positive mindset for all parties. 2) Repeat, repeat and repeat again that it's often possible to write emails without referring, explicitely or implicitely, to people; instead you can just refer to things they say, and discuss in a way that minimizes the risk of offending the author. It's not perfect -- not a very heart-warmed way of talking -- but it's often a good temporary solution to keep communication without surrending to the negative emotions bleeding from a wounded ego.

Mark Stopka

14:12

On Sat, Dec 12, 2020 at 2:56 PM Adrien Glauser wrote:

...

There are few clear-cut and objective criteria for on-topic vs. off-topic. Putting people under moderation on the base of unclear, non-objective criteria might not the best of ideas if you want to build trust and healthy social interactions. Arbitrariness and biases will probably be lurking in about every corner.

Fortunately the on / off -topic is not the most relevant distinction you need to keep the MLs clean. If you need a middle-ground between (dangerously arbitrary, free-speech infringing) moderation and nice but sometimes insufficient abstract rules (such as the Code of Conduct), you can do 2 simple things:

1) Provide a clear path / resolution site for interpersonal conflicts and issues. For example if two people are going two far, you take them apart and iron things out, taming the fire before it spreads over other channels. 1 able person might suffice for doing that for not just the mailing lists but every oS channel. So that instead of punishing, you might end up creating a positive mindset for all parties.

Based on observations in the past few months, I would nominate you as a candidate for such a role in a heartbeat...

...

2) Repeat, repeat and repeat again that it's often possible to write emails without referring, explicitely or implicitely, to people; instead you can just refer to things they say, and discuss in a way that minimizes the risk of offending the author. It's not perfect -- not a very heart-warmed way of talking -- but it's often a good temporary solution to keep communication without surrending to the negative emotions bleeding from a wounded ego. _______________________________________________ openSUSE Project mailing list -- project@lists.opensuse.org To unsubscribe, email project-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/project@lists.opensuse.org

Patrick Shanahan

15:57

* Adrien Glauser [12-12-20 08:58]:

...

There are few clear-cut and objective criteria for on-topic vs. off-topic. Putting people under moderation on the base of unclear, non-objective criteria might not the best of ideas if you want to build trust and healthy social interactions. Arbitrariness and biases will probably be lurking in about every corner.

Fortunately the on / off -topic is not the most relevant distinction you need to keep the MLs clean. If you need a middle-ground between (dangerously arbitrary, free-speech infringing) moderation and nice but sometimes insufficient abstract rules (such as the Code of Conduct), you can do 2 simple things:

1) Provide a clear path / resolution site for interpersonal conflicts and issues. For example if two people are going two far, you take them apart and iron things out, taming the fire before it spreads over other channels. 1 able person might suffice for doing that for not just the mailing lists but every oS channel. So that instead of punishing, you might end up creating a positive mindset for all parties.

2) Repeat, repeat and repeat again that it's often possible to write emails without referring, explicitely or implicitely, to people; instead you can just refer to things they say, and discuss in a way that minimizes the risk of offending the author. It's not perfect -- not a very heart-warmed way of talking -- but it's often a good temporary solution to keep communication without surrending to the negative emotions bleeding from a wounded ego.

this is definitely not the current attitude of the board. and the "board" is unresponsive. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode

Per Jessen

17:30

Adrien Glauser wrote:

...

1) Provide a clear path / resolution site for interpersonal conflicts and issues. For example if two people are going two far, you take them

In the past when we have had such issues (inter-personal, not offtopic), they have usually been deferred to the Board. If deemed appropriate, someone might have been banned for a while, or even for life. Wrt offtopic, I am a strong believer in lists self-policing and also believe it has worked perfectly fine for the last twenty years. There are other topics, such as hate-speech or profanity, where a decision is often easier to make, but even on the latter, sometimes people differ. -- Per Jessen, Zürich (5.1°C) Member, openSUSE Heroes

Adrien Glauser

18:12

I think the notion of an "offtopic issue" makes litle does not survive scrutiny. Well-intentioned people might have different interpretations of the same words, or different interests with respect to the things the words describe. It does not make much sense to moderate people on the basis of just this. The things that *might* justify moderation, in the sense of limiting someone's free speech, have nothing to do with the on / off topic distinction; instead they have to do with people no longer being well-intentioned, or having relational issues. This is a normal thing for any community to have to deal with, and instead of hiding it and trying to cure the symptoms (blocking or removing a bunch of posts) it would be cleverer to treat the root cause (the relational issues). I think many online communities have understood this and perhaps we should take a page or two from their book, by providing a context where relational issues can be sanitized for good.

Per Jessen

18:17

Adrien Glauser wrote:

...

I think the notion of an "offtopic issue" makes litle does not survive scrutiny. Well-intentioned people might have different interpretations of the same words, or different interests with respect to the things the words describe. It does not make much sense to moderate people on the basis of just this.

Completely agree. -- Per Jessen, Zürich (4.1°C) Member, openSUSE Heroes

Fraser_Bell

22:48

On 12/12/20 10:17 AM, Per Jessen wrote:

...

Adrien Glauser wrote:

...
I think the notion of an "offtopic issue" makes litle does not survive scrutiny. Well-intentioned people might have different interpretations of the same words, or different interests with respect to the things the words describe. It does not make much sense to moderate people on the basis of just this.

Completely agree.

I, too, think moderating "off-topic" like this is severe overkill, and counter-productive. Instead, we need to maintain control of trolls and flame-baiters, and those who argue and nitpick at length on mostly irrelevant points, thus derailing important discussions. -- -Gerry Makaro Fraser-Bell on Github

Vinzenz Vietzke

13 Dec 13 Dec

00:12

Am 12.12.20 um 23:48 schrieb Fraser_Bell:

...

Instead, we need to maintain control of trolls and flame-baiters, and those who argue and nitpick at length on mostly irrelevant points, thus derailing important discussions.

Wrt "maintain those whoe argue and nitpick at length on mostly irrelevant points": Bear with me as I'm not a native English speaker and maybe didn't get you right. But wouldn't that be moderating off-topicness? vinz.

Fraser_Bell

14 Dec 14 Dec

00:43

On 12/12/20 4:12 PM, Vinzenz Vietzke wrote:

...

Am 12.12.20 um 23:48 schrieb Fraser_Bell:

...
Instead, we need to maintain control of trolls and flame-baiters, and those who argue and nitpick at length on mostly irrelevant points, thus derailing important discussions.

Wrt "maintain those whoe argue and nitpick at length on mostly irrelevant points":

Bear with me as I'm not a native English speaker and maybe didn't get you right. But wouldn't that be moderating off-topicness?

vinz.

No, not *quite* the same meaning. This is moderating for Guiding Principles and similar. The responses could be fully on-topic, yet still break the above descriptions. So, moderating to keep our mailing lists in friendly, openSUSE Guiding Principles atmosphere would be more constructive than going by off-topicness. See my following reply to Simon. -- -Gerry Makaro openSUSE Member Fraser-Bell on Github

Adrien Glauser

09:21

I couldn't put it better. Also: if ML X or Y have noise, you simply turn up the anti-noise filters, i.e. you require that any *new* poster to the list is not only subscribed but also approved (or: you require that every new user has their 3 first messages approved). So that you: - treat all users equally; - don't have to assemble an offtopic-brigade (you can simply have the person responsible for the ML approve posts and block people who've shown to be unwilling to comply); - apply a preemptive rather than an after-the-fact model (less clean-up, less disruption, less targeting). Perhaps you wanted to do all this anyway, and nothing else. There's been so much claims here that I confess I am no longer sure I can precisely picture the moderation procedure you guys had in mind.

Richard Brown

09:28

On Mon, 2020-12-14 at 09:21 +0000, Adrien Glauser wrote:

...

I couldn't put it better.

Also: if ML X or Y have noise, you simply turn up the anti-noise filters, i.e. you require that any *new* poster to the list is not only subscribed but also approved (or: you require that every new user has their 3 first messages approved).

This assumes new posts are a primary source of noise. If you look at Simon's example of bugreports and support threads on factory, then you'll see at even a casual glance a significant number of those threads are initiated and/or facilitated by long established posters.

...

So that you: - treat all users equally;

You seem to be suggesting we treat new posters worse so all existing posters can be treated "equally" (by not being treated at all).

...

- don't have to assemble an offtopic-brigade (you can simply have the person responsible for the ML approve posts and block people who've shown to be unwilling to comply);

The 'offtopic-brigade' you so derisively name would be establishing persons responsible for the ML, because right now we have no one taking any responsibility for the content of any lists, and that hurts the community and those lists.

Fraser_Bell

23:53

On 12/14/20 1:28 AM, Richard Brown wrote:

...

On Mon, 2020-12-14 at 09:21 +0000, Adrien Glauser wrote:

...
I couldn't put it better.

Also: if ML X or Y have noise, you simply turn up the anti-noise filters, i.e. you require that any *new* poster to the list is not only subscribed but also approved (or: you require that every new user has their 3 first messages approved).

This assumes new posts are a primary source of noise. If you look at Simon's example of bugreports and support threads on factory, then you'll see at even a casual glance a significant number of those threads are initiated and/or facilitated by long established posters.

...
So that you: - treat all users equally;

You seem to be suggesting we treat new posters worse so all existing posters can be treated "equally" (by not being treated at all).

...
- don't have to assemble an offtopic-brigade (you can simply have the person responsible for the ML approve posts and block people who've shown to be unwilling to comply);

The 'offtopic-brigade' you so derisively name would be establishing persons responsible for the ML, because right now we have no one taking any responsibility for the content of any lists, and that hurts the community and those lists. _______________________________________________ openSUSE Project mailing list -- project@lists.opensuse.org To unsubscribe, email project-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/project@lists.opensuse.org

Well said, Richard. I agree completely. -- -Gerry Makaro openSUSE Member Fraser-Bell on Github

Adrien Glauser

15 Dec 15 Dec

11:10

...

I am assuming new posts are a primary source of noise. I wish it was that simple, but nope, that's not correct. Rather this assumes that if use someone's first posts as an opportunity to let them know the ropes, you significantly decrease the probability they will go "offtopic" later.

...

I seem to treat users worse, unequally. Again, this is simplification that you can make for the sake of oneliners, but it's uncalled for. We treat everyone equally *from the point where* we implement the moderation rule I am suggest, because everyone from that point on will have to cope with it. But more importantly, we treat everyone (future and present users) *fairly* (a much more important concept than equality here), because we create a positive environment where the probability for a moderation to have to strike on their own terms is decreased when every had had time to prove they know the ropes. And so doing we decrease (a little bit) the partiality of moderation (validate 3 posts systematically vs. striking impromptu).

...

offtopic brigade I am not here for semantics, I used the word "brigade" to just convey nothing more and nothing less than the idea that they can act unexpected, on their own terms, singling out individuals.

Overall I think the proposal I am making is more reasonable that the one already made, but this is just my opinion. I am thankful for the opportunity I've had to develop it.

Per Jessen

22 Dec 22 Dec

21:38

Richard Brown wrote:

...

On Mon, 2020-12-14 at 09:21 +0000, Adrien Glauser wrote:

...
I couldn't put it better.

Also: if ML X or Y have noise, you simply turn up the anti-noise filters, i.e. you require that any *new* poster to the list is not only subscribed but also approved (or: you require that every new user has their 3 first messages approved).

This assumes new posts are a primary source of noise. If you look at Simon's example of bugreports and support threads on factory, then you'll see at even a casual glance a significant number of those threads are initiated and/or facilitated by long established posters.

So again we have to ask how to provide better support for Tumbleweed?

...

The 'offtopic-brigade' you so derisively name would be establishing persons responsible for the ML, because right now we have no one taking any responsibility for the content of any lists, and that hurts the community and those lists.

Somehow it hasn't done so before, perhaps we ought to ponder why this should be so now? -- Per Jessen, Zürich (9.2°C) Member, openSUSE Heroes

jdd＠dodin.org

13 Dec 13 Dec

08:49

Le 12/12/2020 à 23:48, Fraser_Bell a écrit :

...

Instead, we need to maintain control of trolls and flame-baiters, and those who argue and nitpick at length on mostly irrelevant points, thus derailing important discussions.

may be teach how to kill threads? (K or shift K with thunderbird?). Refraining from answeering such thread is also possible :-). may be flagging some sub thread as "not archived"? I don't know if it's possible :-( jdd -- http://dodin.org

Simon Lees

07:51

On 12/13/20 4:00 AM, Per Jessen wrote:

...

Adrien Glauser wrote:

...
1) Provide a clear path / resolution site for interpersonal conflicts and issues. For example if two people are going two far, you take them

In the past when we have had such issues (inter-personal, not offtopic), they have usually been deferred to the Board. If deemed appropriate, someone might have been banned for a while, or even for life.

I imagine the board will continue to deal with the more complex cases an if someone disagrees with a moderator they can escalate it to the board.

...

Wrt offtopic, I am a strong believer in lists self-policing and also believe it has worked perfectly fine for the last twenty years.

The evidence from the last few years seems to show that this is something that is simply not working for the factory list.

...

There are other topics, such as hate-speech or profanity, where a decision is often easier to make, but even on the latter, sometimes people differ.

We would like to move to the model we use in the forums / Discord / IRC where moderators have some power to enforce community standards and rules while still leaving the board as the final conflict resolution mechanism. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Per Jessen

19:35

Simon Lees wrote:

...

...
Wrt offtopic, I am a strong believer in lists self-policing and also believe it has worked perfectly fine for the last twenty years.

The evidence from the last few years seems to show that this is something that is simply not working for the factory list.

Simon, do you have any actual evidence to present? I mean, over "the last few years", how many threads have gone off-topic, seen relatively to the number of threads that have not. I really think we have to keep things in perspective. Factual rather than anecdotal. I wonder if the issue we (as a community) have with factory.lists, is about support for Tumbleweed. People/users look to us for help with Tumbleweed, which is most easily available on factory, but as user questions are most often not development related, they are essentially considered off-topic. I suggest _that_ problem would be best solved by us proving better support for a main openSUSE distro. Setting up an offtopic police is just knee-jerk non-sense.

...

...
There are other topics, such as hate-speech or profanity, where a decision is often easier to make, but even on the latter, sometimes people differ.

We would like to move to the model we use in the forums / Discord / IRC where moderators have some power to enforce community standards and rules while still leaving the board as the final conflict resolution mechanism.

If "we" == "the board", I think that is a very important statement to make. I would immediately tender my list manager's "job" if we were ever to pursue such non-sense. -- Per Jessen, Zürich (3.7°C) Member, openSUSE Heroes

Carlos E. R.

19:45

On 13/12/2020 20.35, Per Jessen wrote:

...

Simon Lees wrote:

...
...
Wrt offtopic, I am a strong believer in lists self-policing and also believe it has worked perfectly fine for the last twenty years.

The evidence from the last few years seems to show that this is something that is simply not working for the factory list.

Simon, do you have any actual evidence to present? I mean, over "the last few years", how many threads have gone off-topic, seen relatively to the number of threads that have not. I really think we have to keep things in perspective. Factual rather than anecdotal.

I wonder if the issue we (as a community) have with factory.lists, is about support for Tumbleweed. People/users look to us for help with Tumbleweed, which is most easily available on factory, but as user questions are most often not development related, they are essentially considered off-topic.

Yes, this is so. Many questions people have with Tumbleweed are new problems that nobody in the user community know about. Only the people that have done the work can possibly know something about those changes, new features, new problems. Or new bugs.

...

I suggest _that_ problem would be best solved by us proving better support for a main openSUSE distro. Setting up an offtopic police is just knee-jerk non-sense.

Absolutely.

...

...
...
There are other topics, such as hate-speech or profanity, where a decision is often easier to make, but even on the latter, sometimes people differ.

We would like to move to the model we use in the forums / Discord / IRC where moderators have some power to enforce community standards and rules while still leaving the board as the final conflict resolution mechanism.

If "we" == "the board", I think that is a very important statement to make. I would immediately tender my list manager's "job" if we were ever to pursue such non-sense.

-- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

Simon Lees

14 Dec 14 Dec

00:04

On 12/14/20 6:05 AM, Per Jessen wrote:

...

Simon Lees wrote:

...
...
Wrt offtopic, I am a strong believer in lists self-policing and also believe it has worked perfectly fine for the last twenty years.

The evidence from the last few years seems to show that this is something that is simply not working for the factory list.

Simon, do you have any actual evidence to present? I mean, over "the last few years", how many threads have gone off-topic, seen relatively to the number of threads that have not. I really think we have to keep things in perspective. Factual rather than anecdotal.

I wonder if the issue we (as a community) have with factory.lists, is about support for Tumbleweed. People/users look to us for help with Tumbleweed, which is most easily available on factory, but as user questions are most often not development related, they are essentially considered off-topic.

I suggest _that_ problem would be best solved by us proving better support for a main openSUSE distro. Setting up an offtopic police is just knee-jerk non-sense.

This is a Volunteer project, support is provided on a best effort basis by volunteers. We have asked everyone interested in providing support to join the dedicated support list. It is not someones right to post a question to a developer list and expect an answer because they don't believe they will get it elsewhere. We have had many complaints from developers about the "Noise" on that list which has lead to some people unsubscribing and or missing important discussions. The other frequent cause of "Noise" is bug reports about something in a new snapshot by posting to the list these waste a small amount of all developers time where as when posted to the bugtracker only the relevant devs need be reported. If a maintainer decided that something is a significant issue likely to affect a large number of people then they may choose to post a warning to the list but that is not its main purpose. As a broader question to the community do we need such a list for tumbleweed announcements and reports of major breakages? The answer we got last time was no. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Stefan Seyfried

15 Dec 15 Dec

18:56

On 14.12.20 01:04, Simon Lees wrote:

...

The other frequent cause of "Noise" is bug reports about something in a new snapshot by posting to the list these waste a small amount of all developers time where as when posted to the bugtracker only the relevant devs need be reported.

That's your view of the issue. Mine is different. The mails on factory which I read with high priority are: * "New Tumbleweed Snapshot released" => to check what changed and if this warrants a timely update * The responses to "New Tumbleweed Snapshot released", preferrably with a good subject line. => to quickly get an overview if this snapshot has rough edges and if I probably should defer my update. Checking bugzilla for every possible bug before updating is just not possible. TBH it's pretty hard to find anything in bugzilla at all. The only searches that work reliably for me are the "bugs assigned to email X" style of searches, but useful content search? Nope. And then many bugs just won't get reported. I am not going to report a possible bug that I might have found if I'm not quite sure it is a bug and not a user / config error. Or if it is simply not that reproducible but only happens "sometimes". If questions like "after update to this snapshot, my sshd does no longer let me log in, does anyone else see that?" are no longer allowed on factory, then please immediately unsubscribe me. Yes, strictly speaking this is a support question. But it is as well a question that hints everyone that there might be a dire problem on sshd. The two following answers like "no, works for me, must be your setup" are also "noise" on the factory list, but these are useful for the interested reader because they convey that the problem might not be a general one and updating might be safe after all. Of course if other people answer me "no, must be your setup" and maybe even give me some nice hints on how to debug the problem, I will in the end create a bug report. And -- differently from the "just create a bug report anyway -- it will possibly not be created against openssh but the library whose change broke my usecase and thus bu much better.

...

If a maintainer decided that something is a significant issue likely to affect a large number of people then they may choose to post a warning to the list but that is not its main purpose.

And if the maintainer does bugzilla maintenance on a monthly base or the bug simply only gets assigned to him half a year later, he will never know that there is a problem. I know this happens. From experience. When I was still doing XFCE bugfixing, I had to actively search for XFCE bugs, since they were assigned to whomever but not to me. Or bluez bugs. Assigned to nobody, some screening team or whomever, but I never saw them and thus they did not get fixed. (bluez bugs assignment has improved in the last years).

...

As a broader question to the community do we need such a list for tumbleweed announcements and reports of major breakages? The answer we got last time was no.

Because the canary "lots of answers to a tumbleweed announcement? => better be careful" works very well without another list. I also cannot even find a factory-support list at all? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

Adrien Glauser

22:54

Per has been asking for evidence in an earlier message above. I share his interest and I think your message invites the idea that the following possibilities are still live and kickin' despite everything people have written on this topic, namely that: 1. Maybe what is welcome or unwelcome on the Factory ML is not adequately made clear and explained to people; 2. Maybe there is demand for something which several people see in the Factory ML, and which motivates them to take risks they would not have taken otherwise. So perhaps it all started on the wrong foot -- perhaps we should be talking about information, visibility and demand, instead of moderation.

Neal Gompa

16 Dec 16 Dec

22:14

On Tue, Dec 15, 2020 at 1:56 PM Stefan Seyfried wrote:

...

On 14.12.20 01:04, Simon Lees wrote:

...
As a broader question to the community do we need such a list for tumbleweed announcements and reports of major breakages? The answer we got last time was no.

Because the canary "lots of answers to a tumbleweed announcement? => better be careful" works very well without another list.

I also cannot even find a factory-support list at all?

In my opinion, the factory@ mailing list is a poorly named one. It's pretty clear from how people respond to folks asking questions about Tumbleweed that it's purely a "development" list. It is also pretty clear that factory@ isn't just about Factory development, but pretty much *all* development of the openSUSE Linux distributions (since we do talk about openSUSE Leap here too), and it would be more appropriate to rename it to devel@. To me, I think it would make sense to have devel-announce@ for the announcement emails, but the issue with that is that we rely on users replying to those emails on-list to get feedback about specific issues with those snapshots, hence why they are sent to factory@ today (and would be sent to devel@ if we renamed this list). On the other hand, having a devel-announce@ list would make it possible for folks to subscribe to *just* those emails in a read-only manner. What I do know is that generally speaking, factory@ is a terrible place for users to get help, but there are currently no better options. -- 真実はいつも一つ！/ Always, there's only one truth!

Gerald Pfeifer

22:30

On Wed 2020-12-16, Neal Gompa wrote:

...

In my opinion, the factory@ mailing list is a poorly named one. It's pretty clear from how people respond to folks asking questions about Tumbleweed that it's purely a "development" list.

It is also pretty clear that factory@ isn't just about Factory development, but pretty much *all* development of the openSUSE Linux distributions (since we do talk about openSUSE Leap here too), and it would be more appropriate to rename it to devel@.

I think I follow you and agree, except on the very last word ;-), given that openSUSE is about more than Linux (or GNU/Linux) distros.

...

To me, I think it would make sense to have devel-announce@ for the announcement emails

So linux-devel@ and linux-announce@ ? Or probably factory-devel@, factory-announce@, leap-devel@ and leap-announce?

...

but the issue with that is that we rely on users replying to those emails on-list to get feedback about specific issues

There could be a note in announcements to "please direct responses to ...; this list is for announcements only", maybe even including a Reply-To: header?

...

What I do know is that generally speaking, factory@ is a terrible place for users to get help, but there are currently no better options.

factory-help@ or factory-support@ ? Gerald

Jim Henderson

22:37

On Wed, 16 Dec 2020 23:30:00 +0100, Gerald Pfeifer wrote:

...

...
It is also pretty clear that factory@ isn't just about Factory development, but pretty much *all* development of the openSUSE Linux distributions (since we do talk about openSUSE Leap here too), and it would be more appropriate to rename it to devel@.

I think I follow you and agree, except on the very last word ;-), given that openSUSE is about more than Linux (or GNU/Linux) distros.

Interestingly, whomever set it up on gmane set factory up as devel (ie, the newsgroup is gmane.linux.suse.opensuse.devel). Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits

Per Jessen

22 Dec 22 Dec

21:46

Gerald Pfeifer wrote:

...

On Wed 2020-12-16, Neal Gompa wrote:

...
In my opinion, the factory@ mailing list is a poorly named one. It's pretty clear from how people respond to folks asking questions about Tumbleweed that it's purely a "development" list.

It is also pretty clear that factory@ isn't just about Factory development, but pretty much *all* development of the openSUSE Linux distributions (since we do talk about openSUSE Leap here too), and it would be more appropriate to rename it to devel@.

I think I follow you and agree, except on the very last word ;-), given that openSUSE is about more than Linux (or GNU/Linux) distros.

...
To me, I think it would make sense to have devel-announce@ for the announcement emails

So linux-devel@ and linux-announce@ ?

Or probably factory-devel@, factory-announce@, leap-devel@ and leap-announce?

...
but the issue with that is that we rely on users replying to those emails on-list to get feedback about specific issues

There could be a note in announcements to "please direct responses to ...; this list is for announcements only", maybe even including a Reply-To: header?

...
What I do know is that generally speaking, factory@ is a terrible place for users to get help, but there are currently no better options.

factory-help@ or factory-support@ ?

Gerald, it is not about the _naming_ of mailing lists or fora or channels or whatever - it is about bringing the people offering support together with the people seeking support. That's all. I admit I have no easy solution either, but renaming or splitting lists will do no good. -- Per Jessen, Zürich (9.2°C) Member, openSUSE Heroes

Simon Lees

23:33

On 12/23/20 8:16 AM, Per Jessen wrote:

...

Gerald Pfeifer wrote:

...
On Wed 2020-12-16, Neal Gompa wrote:

...
What I do know is that generally speaking, factory@ is a terrible place for users to get help, but there are currently no better options.

factory-help@ or factory-support@ ?

Gerald, it is not about the _naming_ of mailing lists or fora or channels or whatever - it is about bringing the people offering support together with the people seeking support. That's all. I admit I have no easy solution either, but renaming or splitting lists will do no good.

I somewhat disagree here, Several years back we asked everyone on opensuse@ and factory@ who was interested in providing support to join support@, other then a few people continuing to post on factory this has worked reasonably well. However we now have a naming issue as its unclear whether users@ or support@ is the right place, especially on the main lists page, even in your reply to stefan you put users@ above support@, previously there was only one official answer to that question which was support@ even though you could often get support at the older opensuse@ that wasn't advertised anywhere to make it non confusing to new people. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Per Jessen

21:42

Neal Gompa wrote:

...

What I do know is that generally speaking, factory@ is a terrible place for users to get help, but there are currently no better options.

Very nicely summarised, Neal. Big +1 -- Per Jessen, Zürich (9.2°C) Member, openSUSE Heroes

Simon Lees

23:08

On 12/17/20 8:44 AM, Neal Gompa wrote:

...

On Tue, Dec 15, 2020 at 1:56 PM Stefan Seyfried wrote:

...
On 14.12.20 01:04, Simon Lees wrote:

...
As a broader question to the community do we need such a list for tumbleweed announcements and reports of major breakages? The answer we got last time was no.

Because the canary "lots of answers to a tumbleweed announcement? => better be careful" works very well without another list.

I also cannot even find a factory-support list at all?

In my opinion, the factory@ mailing list is a poorly named one. It's pretty clear from how people respond to folks asking questions about Tumbleweed that it's purely a "development" list.

It is also pretty clear that factory@ isn't just about Factory development, but pretty much *all* development of the openSUSE Linux distributions (since we do talk about openSUSE Leap here too), and it would be more appropriate to rename it to devel@.

This was discussed in the past but didn't have strong support in the community because in openSUSE Factory has always equaled devel.

...

To me, I think it would make sense to have devel-announce@ for the announcement emails, but the issue with that is that we rely on users replying to those emails on-list to get feedback about specific issues with those snapshots, hence why they are sent to factory@ today (and would be sent to devel@ if we renamed this list). On the other hand, having a devel-announce@ list would make it possible for folks to subscribe to *just* those emails in a read-only manner.

I also don't think an announce is the right answer either, but maybe moving to having a devel- for all development discussion and a tumbleweed list to cover announcements and reports of issues (with accompanying bug report because I wouldn't expect all maintainers to subscribe.) might be the way to go. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Per Jessen

21:41

Stefan Seyfried wrote:

...

I also cannot even find a factory-support list at all?

As Tumbleweed is a regular openSUSE distribution, the support mailing lists are: users@lists.opensuse.org (English) or user-xx@lists.opensuse.org (in xx). or support@lists.opensuse.org (in English) -- Per Jessen, Zürich (9.4°C) Member, openSUSE Heroes

Carlos E. R.

23 Dec 23 Dec

22:00

On 15/12/2020 19.56, Stefan Seyfried wrote:

...

On 14.12.20 01:04, Simon Lees wrote:

...
The other frequent cause of "Noise" is bug reports about something in a new snapshot by posting to the list these waste a small amount of all developers time where as when posted to the bugtracker only the relevant devs need be reported.

That's your view of the issue. Mine is different.

The mails on factory which I read with high priority are:

* "New Tumbleweed Snapshot released" => to check what changed and if this warrants a timely update * The responses to "New Tumbleweed Snapshot released", preferrably with a good subject line. => to quickly get an overview if this snapshot has rough edges and if I probably should defer my update.

Absolutely. I do the same, but as I don't /use/ tumbleweed, I read with the purpose of helping users that come later asking about an issue (perhaps in other lists). It may be an issue I read about here. It is the main job I do as volunteer.

...

Checking bugzilla for every possible bug before updating is just not possible. TBH it's pretty hard to find anything in bugzilla at all. The only searches that work reliably for me are the "bugs assigned to email X" style of searches, but useful content search? Nope.

And then many bugs just won't get reported. I am not going to report a possible bug that I might have found if I'm not quite sure it is a bug and not a user / config error. Or if it is simply not that reproducible but only happens "sometimes".

If questions like "after update to this snapshot, my sshd does no longer let me log in, does anyone else see that?" are no longer allowed on factory, then please immediately unsubscribe me.

Yes, the factory list would lose a lot of its usefulness.

...

Yes, strictly speaking this is a support question. But it is as well a question that hints everyone that there might be a dire problem on sshd. The two following answers like "no, works for me, must be your setup" are also "noise" on the factory list, but these are useful for the interested reader because they convey that the problem might not be a general one and updating might be safe after all.

Of course if other people answer me "no, must be your setup" and maybe even give me some nice hints on how to debug the problem, I will in the end create a bug report. And -- differently from the "just create a bug report anyway -- it will possibly not be created against openssh but the library whose change broke my usecase and thus bu much better.

Yes, you are correct.

...

...
If a maintainer decided that something is a significant issue likely to affect a large number of people then they may choose to post a warning to the list but that is not its main purpose.

And if the maintainer does bugzilla maintenance on a monthly base or the bug simply only gets assigned to him half a year later, he will never know that there is a problem.

I know this happens. From experience. When I was still doing XFCE bugfixing, I had to actively search for XFCE bugs, since they were assigned to whomever but not to me. Or bluez bugs. Assigned to nobody, some screening team or whomever, but I never saw them and thus they did not get fixed. (bluez bugs assignment has improved in the last years).

...
As a broader question to the community do we need such a list for tumbleweed announcements and reports of major breakages? The answer we got last time was no.

Because the canary "lots of answers to a tumbleweed announcement? => better be careful" works very well without another list.

I also cannot even find a factory-support list at all?

In theory, it should be the "support@..." mail list. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

Simon Lees

24 Dec 24 Dec

00:08

On 12/24/20 8:30 AM, Carlos E. R. wrote:

...

On 15/12/2020 19.56, Stefan Seyfried wrote:

...
On 14.12.20 01:04, Simon Lees wrote:

...
The other frequent cause of "Noise" is bug reports about something in a new snapshot by posting to the list these waste a small amount of all developers time where as when posted to the bugtracker only the relevant devs need be reported.

That's your view of the issue. Mine is different.

The mails on factory which I read with high priority are:

* "New Tumbleweed Snapshot released" => to check what changed and if this warrants a timely update * The responses to "New Tumbleweed Snapshot released", preferrably with a good subject line. => to quickly get an overview if this snapshot has rough edges and if I probably should defer my update.

Absolutely.

I do the same, but as I don't /use/ tumbleweed, I read with the purpose of helping users that come later asking about an issue (perhaps in other lists). It may be an issue I read about here. It is the main job I do as volunteer.

...
Checking bugzilla for every possible bug before updating is just not possible. TBH it's pretty hard to find anything in bugzilla at all. The only searches that work reliably for me are the "bugs assigned to email X" style of searches, but useful content search? Nope.

And then many bugs just won't get reported. I am not going to report a possible bug that I might have found if I'm not quite sure it is a bug and not a user / config error. Or if it is simply not that reproducible but only happens "sometimes".

If questions like "after update to this snapshot, my sshd does no longer let me log in, does anyone else see that?" are no longer allowed on factory, then please immediately unsubscribe me.

Yes, the factory list would lose a lot of its usefulness.

At the time the board decided there probably wasn't enough demand for a mailing list dedicated to new tumbleweed snapshots + reports of issues for other users (We expect developers to be notified of issues by tickets in the bugtracker). Would a dedicated list for the tumbleweed snapshot email and the usecase you describe above away from the main development list work for both of you? If this is something the community would find useful we can look at it in the new year. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Per Jessen

22 Dec 22 Dec

21:30

Simon Lees wrote:

...

On 12/14/20 6:05 AM, Per Jessen wrote:

...
Simon Lees wrote:

...
...
Wrt offtopic, I am a strong believer in lists self-policing and also believe it has worked perfectly fine for the last twenty years.

The evidence from the last few years seems to show that this is something that is simply not working for the factory list.

Simon, do you have any actual evidence to present? I mean, over "the last few years", how many threads have gone off-topic, seen relatively to the number of threads that have not. I really think we have to keep things in perspective. Factual rather than anecdotal.

I wonder if the issue we (as a community) have with factory.lists, is about support for Tumbleweed. People/users look to us for help with Tumbleweed, which is most easily available on factory, but as user questions are most often not development related, they are essentially considered off-topic.

I suggest _that_ problem would be best solved by us proving better support for a main openSUSE distro. Setting up an offtopic police is just knee-jerk non-sense.

This is a Volunteer project, support is provided on a best effort basis by volunteers.

Again, my apologies for a late reply, that time of year etc etc. I too am a volunteer, even if I may have community obligations that mean I cannot just react on a "best effort" basis.

...

We have asked everyone interested in providing support to join the dedicated support list.

I suggest you (the Board) have obviously failed in attracting sufficiently of those which means people are looking elsewhere for support, such that even esteemed board members ask TW questions on factory.lists. Having two-three lists offering support is simply confusing.

...

It is not someones right to post a question to a developer list and expect an answer because they don't believe they will get it elsewhere.

What happens when they don't get it elsewhere?

...

We have had many complaints from developers about the "Noise" on that list which has lead to some people unsubscribing and or missing important discussions.

I guess it is prudent to note that developers are nothing without users, just as users are nothing without developers. Simon, you neglected to actually address the problem I brought up :

...

...
I wonder if the issue we (as a community) have with factory.lists, is about support for Tumbleweed. People/users look to us for help with Tumbleweed, which is most easily available on factory, but as user questions are most often not development related, they are essentially considered off-topic.

Obviously you are not expected to single-handedly solve this issue. -- Per Jessen, Zürich (9.4°C) Member, openSUSE Heroes

Simon Lees

23 Dec 23 Dec

00:27

On 12/23/20 8:00 AM, Per Jessen wrote:

...

Simon Lees wrote:

...
On 12/14/20 6:05 AM, Per Jessen wrote:

...
Simon Lees wrote:

I suggest _that_ problem would be best solved by us proving better support for a main openSUSE distro. Setting up an offtopic police is just knee-jerk non-sense.

This is a Volunteer project, support is provided on a best effort basis by volunteers.

Again, my apologies for a late reply, that time of year etc etc.

I too am a volunteer, even if I may have community obligations that mean I cannot just react on a "best effort" basis.

...
We have asked everyone interested in providing support to join the dedicated support list.

I suggest you (the Board) have obviously failed in attracting sufficiently of those which means people are looking elsewhere for support, such that even esteemed board members ask TW questions on factory.lists. Having two-three lists offering support is simply confusing.

Yes we have a naming problem, we have one place where we would like people to go for support but 2-3 places that could seem like a good place to go for support.

...

...
It is not someones right to post a question to a developer list and expect an answer because they don't believe they will get it elsewhere.

What happens when they don't get it elsewhere?

In many cases there are places they can go, such as upstream communities etc who are often more knowledgeable on specific topics, if they really need a guarantee of help then they should also consider a distro with enterprise grade support such as SLE. I have also been around long enough to know there are some questions that no one can figure out.

...

...
We have had many complaints from developers about the "Noise" on that list which has lead to some people unsubscribing and or missing important discussions.

I guess it is prudent to note that developers are nothing without users, just as users are nothing without developers.

Agreed, however users need to respect developers time especially volunteer developers who only have limited time. In the same way developers should respect users time by not releasing untested code and expecting users to test and find all the bugs.

...

Simon, you neglected to actually address the problem I brought up :

...
...
I wonder if the issue we (as a community) have with factory.lists, is about support for Tumbleweed. People/users look to us for help with Tumbleweed, which is most easily available on factory, but as user questions are most often not development related, they are essentially considered off-topic.

Maybe, however from my experience there are many developers who were subscribed to opensuse@ to provide support, who left because of the volume of off topic traffic (a similar thing was happening with factory@ hence the changes), so some of the challenge is convincing developers that subscribing to support@ is worth there time again. There is also a legacy factor in that before tumbleweed was a distro and we only had factory and it wasn't used by a large number of users the factory list was the right place to ask. With a development community our size we need a clear place for development discussions where a large percentage of developers feel comfortable to subscribe and contribute, the feedback we as the board were getting was a number of developers were unsubscribing or considering unsubscribing from factory@ due to the fact it was no longer mostly development discussion so as a board we had to act in some way. I guess another alternative could have been creating a new devel list and leaving factory as it was but then we still would have had multiple places for support so we decided to try and consolidate that instead before deciding on any further action. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Carlos E. R.

21:54

On 23/12/2020 01.27, Simon Lees wrote:

...

On 12/23/20 8:00 AM, Per Jessen wrote:

...
Simon Lees wrote:

...
On 12/14/20 6:05 AM, Per Jessen wrote:

...
Simon Lees wrote:

....

...

...
...
...
I suggest _that_ problem would be best solved by us proving better support for a main openSUSE distro. Setting up an offtopic police is just knee-jerk non-sense.

This is a Volunteer project, support is provided on a best effort basis by volunteers.

Again, my apologies for a late reply, that time of year etc etc.

I too am a volunteer, even if I may have community obligations that mean I cannot just react on a "best effort" basis.

...
We have asked everyone interested in providing support to join the dedicated support list.

I suggest you (the Board) have obviously failed in attracting sufficiently of those which means people are looking elsewhere for support, such that even esteemed board members ask TW questions on factory.lists. Having two-three lists offering support is simply confusing.

Yes.

...

Yes we have a naming problem, we have one place where we would like people to go for support but 2-3 places that could seem like a good place to go for support.

...
...
It is not someones right to post a question to a developer list and expect an answer because they don't believe they will get it elsewhere.

What happens when they don't get it elsewhere?

In many cases there are places they can go, such as upstream communities etc who are often more knowledgeable on specific topics, if they really need a guarantee of help then they should also consider a distro with enterprise grade support such as SLE. I have also been around long enough to know there are some questions that no one can figure out.

...
...
We have had many complaints from developers about the "Noise" on that list which has lead to some people unsubscribing and or missing important discussions.

I guess it is prudent to note that developers are nothing without users, just as users are nothing without developers.

Agreed, however users need to respect developers time especially volunteer developers who only have limited time. In the same way developers should respect users time by not releasing untested code and expecting users to test and find all the bugs.

And they should also be grateful to read what people comment about whatever code they do, too. Specially with people that use bleeding edge things: those users run a risk and apply extra effort because they are the first that actually use new code. They will be the ones to find out things, both wonderful or bad. ... -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

Simon Lees

24 Dec 24 Dec

02:47

On 12/24/20 8:24 AM, Carlos E. R. wrote:

...

On 23/12/2020 01.27, Simon Lees wrote:

...
Agreed, however users need to respect developers time especially volunteer developers who only have limited time. In the same way developers should respect users time by not releasing untested code and expecting users to test and find all the bugs.

And they should also be grateful to read what people comment about whatever code they do, too. Specially with people that use bleeding edge things: those users run a risk and apply extra effort because they are the first that actually use new code. They will be the ones to find out things, both wonderful or bad. Yes but the factory mailing list is far from a good place to do this. By contacting people on that list you are communicating with **all** openSUSE developers and one maybe two or even none of the developers who need such feedback (In many cases openSUSE packages are not upstream developers, but may provide occasional feedback).

Instead to provide this kind of feedback you are much better off contacting the upstream community directly. Its also worth noting that by most upstream's standards Tumbleweed isn't that bleeding edge as generally tumbleweed runs upstream's latest release of things not there beta / testing variants. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Stefan Seyfried

11:06

On 24.12.20 03:47, Simon Lees wrote:

...

Instead to provide this kind of feedback you are much better off contacting the upstream community directly. Yes, a good way to help newcomers.

"Oh, your new WiFi USB stick that you made working by adding the ID to $driver.c? Just report it upstream at linux-kernel@vger". And then let him endure the "checkpatch.pl is wrong", "signed-off-by line is missing", "...". He'll for sure never contribute again. Instead we could just use his report, fix the contribution up to the upstream standards and submit it (with proper attribution of course). BTDT. https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/H... => 166cb70e97bd83d7ae9bbec6ae59a178fd9bb823 Or when I experienced a strange memleakin the kernel some years ago. I did not even know where to look. Of course I could have asked on linux-kernel directly, but the amount of information that I could have given there would probably have lead to zero answers. Asking here on factory (oh no, it was opensuse-kernel, but if it would have been not a kernel problem, I would have asked on factory, so this is still relevant) connected me with people helping me to find the information to actually report and fix the problem. https://lists.opensuse.org/archives/list/kernel@lists.opensuse.org/thread/GJ... => 848e616e66d4592fe9afc40743d3504deb7632b4

...

Its also worth noting that by most upstream's standards Tumbleweed isn't that bleeding edge as generally tumbleweed runs upstream's latest release of things not there beta / testing variants.

...and because of that reports are often not that useful. Because the answer is then "that's fixed weeks ago in latest git head" or such... I know there are obnoxious off-topic posters, and I sometimes catch myself driving off on a tangent, but hey, people that have spend more than 4 weeks on the factory list know very well that "oh, the topic has moved to "OBS BOTS" and seife answered, let's just ignore the whole subthread". Works much better IMHO than telling every poster that asks for help in respone to a "new tumbleweed snapshot" announce mail that he should open a bug report (of course without helping him on his actual problem). And there are some people on the list that are just in my ignore filter. Helps me keep my mental stability ;-) Executive summary: your goal seems to be to reduce the number of mailing list posts to factory at any cost. The easiest way to achieve that is to just close the list. Then you do not need to read anything you consider off topic there. *THE NEXT SENTENCE IS A JOKE* (nowadays, nobody seems to get sarcasm if not pointed out explicitly) <JOKE> Or just unsubscribe yourself (would also reduce the number of mails for everyone ;-) </JOKE> -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

Per Jessen

25 Dec 25 Dec

21:54

Simon Lees wrote:

...

On 12/23/20 8:00 AM, Per Jessen wrote:

...
...
We have asked everyone interested in providing support to join the dedicated support list.

I suggest you (the Board) have obviously failed in attracting sufficiently of those which means people are looking elsewhere for support, such that even esteemed board members ask TW questions on factory.lists. Having two-three lists offering support is simply confusing.

Yes we have a naming problem, we have one place where we would like people to go for support but 2-3 places that could seem like a good place to go for support.

It is really not a matter of naming, I would suggest. If we have a single place where we (as a community) offer support for our distributions, people will come. I think that is what we need to focus on, not what to name it.

...

...
...
It is not someones right to post a question to a developer list and expect an answer because they don't believe they will get it elsewhere.

What happens when they don't get it elsewhere?

In many cases there are places they can go, such as upstream communities etc who are often more knowledgeable on specific topics,

Whereas they will have little idea what has just gone into openSUSE.

...

if they really need a guarantee of help then they should also consider a distro with enterprise grade support such as SLE.

Please Simon, can we stick to the topic at hand? Nobody is asking about gurantees. We are talking about people who might feel it is his/her "right to post a question to a developer list and expect an answer" - iow, we are talking Tumbleweed, not Leap and not SLE.

...

I have also been around long enough to know there are some questions that no one can figure out.

Certainly there is, but that is surely irrelevant?

...

...
...
We have had many complaints from developers about the "Noise" on that list which has lead to some people unsubscribing and or missing important discussions.

I guess it is prudent to note that developers are nothing without users, just as users are nothing without developers.

Agreed, however users need to respect developers time especially volunteer developers who only have limited time. In the same way developers should respect users time by not releasing untested code and expecting users to test and find all the bugs.

I also suggest developers and maintainers ought to recognise and accept their responsibility to support their users.

...

...
Simon, you neglected to actually address the problem I brought up :

...
...
I wonder if the issue we (as a community) have with factory.lists, is about support for Tumbleweed. People/users look to us for help with Tumbleweed, which is most easily available on factory, but as user questions are most often not development related, they are essentially considered off-topic.

Maybe, however from my experience there are many developers who were subscribed to opensuse@ to provide support, who left because of the volume of off topic traffic (a similar thing was happening with factory@ hence the changes), so some of the challenge is convincing developers that subscribing to support@ is worth there time again.

If you were to check it out, you'll find plenty of off-topic chitter-chatter on the support list too.

...

With a development community our size we need a clear place for development discussions where a large percentage of developers feel comfortable to subscribe and contribute,

Agree. Also, with a user community our size we need a clear place for user support where a large percentage of users feel comfortable to subscribe and receive qualified support. Also for Tumbleweed, which we are promoting as a key openSUSE distro.

...

the feedback we as the board were getting was a number of developers were unsubscribing or considering unsubscribing from factory@ due to the fact it was no longer mostly development discussion so as a board we had to act in some way. I guess another alternative could have been creating a new devel list and leaving factory as it was but then we still would have had multiple places for support so we decided to try and consolidate that instead before deciding on any further action.

All water under the bridge, let us ignore whatever bad decisions were made and focus on what to do now. For starters, I say merge the support lists back into to the users list. Then I suggest tasking the Board with finding ideas for how to improve support for Tumbleweed users, without clogging up the factory list. -- Per Jessen, Zürich (-0.2°C) Member, openSUSE Heroes

Patrick Shanahan

22 Dec 22 Dec

23:39

* Simon Lees [12-13-20 02:55]:

...

On 12/13/20 4:00 AM, Per Jessen wrote:

...
Adrien Glauser wrote:

...
1) Provide a clear path / resolution site for interpersonal conflicts and issues. For example if two people are going two far, you take them

In the past when we have had such issues (inter-personal, not offtopic), they have usually been deferred to the Board. If deemed appropriate, someone might have been banned for a while, or even for life.

I imagine the board will continue to deal with the more complex cases an if someone disagrees with a moderator they can escalate it to the board.

I cannot believe that would work. It does not now, at least from personal experience.

...

...
Wrt offtopic, I am a strong believer in lists self-policing and also believe it has worked perfectly fine for the last twenty years.

The evidence from the last few years seems to show that this is something that is simply not working for the factory list.

...
There are other topics, such as hate-speech or profanity, where a decision is often easier to make, but even on the latter, sometimes people differ.

We would like to move to the model we use in the forums / Discord / IRC where moderators have some power to enforce community standards and rules while still leaving the board as the final conflict resolution mechanism.

-- Simon Lees (Simotek) http://simotek.net

Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

...

_______________________________________________ openSUSE Project mailing list -- project@lists.opensuse.org To unsubscribe, email project-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/project@lists.opensuse.org

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode

Linda A. Walsh

17 Dec 17 Dec

19:16

New subject: automation of Managing list offtopicness (was: Re: Managing list offtopicness better.)

Some initial comments on severity of penalties, and possible idea for automatically handling some problems.... On 2020/12/12 09:30, Per Jessen wrote:

...

If deemed appropriate, someone might have been banned for a while, or even for life.

Even in the case of murder, parole is possible depending on circumstances. Are people committing offenses on this list such that lifetime banishment should even be considered? The idea that someone should be banned for life for anything consisting solely of a list post, seems entirely excessive. Add them to a spam list that expires in a year, at most, but be reasonable. If they violate anything again, add them again, but realize a lifetime ban really encourages them getting one or more alternate email accounts from which they can easily snipe with impunity. Even a year is a long time in the internet community -- and remember, once you've enacted such a penalty, you are done. There's not much else you can do to influence their behavior, with a "lifetime" ban essentially saying that there is no way "someone like them" can ever change, grow or correct their behavior. Also, I can't say this is true for everyone, but from personal experience, I've been subject to, maybe 3-4 bans, none of which was for valid cause when the original postings were examined. In at least 1-2 situations, the organization (or person) involved was made redundant, dissolved, shut-down or defunded due, most often, to similarly ill-handled situations. Possible way to handle: Personally, I'd try to develop an automated approach -- literally a Bayesian filter that could stop a posting before it is distributed and send the posting back to the user with comments like: "This posting looks like it might contain:" "offensive language", "offensive style", "minority marginalization", or "XXYZ". "If you are sure you wish to send this, please add a line at the end with the text: Confirm post. On a line by itself, within 5 lines of the end (the line will be removed before being passed onto the list)". ==== As part of the list-footer, give a non-clickable URL (need to cut+paste into a browser) with a unique messageID that leads to a page where list-members can add a vote regarding the post as to it most matching one of the banned topics (it may match more than one, but indicate only 1 topic that best fits the circumstance). Votes would only be allowed to list members as verified by user-login by-email to a site, OR by sending an email from a list-user email with the email-ID of the email being evaluated+its category. Note: categories could be positive areas as well for building up kudos or bonuses for a given topic. ==== Ratings for email-types would be built up over time with # of users out of #-readers marking a post as 'matching'. Evaluations would be limited to votes associated with 1 poster, at most, 'N' times (1 or 2?)/day per poster. Blah blah blah....further design TBD as needed.... This way people can, AT FIRST, get preliminary feedback that what they are posting may be considered offensive. Depending on the strength of matched scores, and number of warning-overrides used, someone could be given an automatic cooldown period of "N" days or weeks (or months) -- which, ALSO, could be seen as a temporary 'posting ban' for that period. The automation of this process would hopefully reduce or eliminate reactionary, vigilante, and/or emotional actions. Preferably, the software would be open-sourced to allow other lists to use it as well as making "bot" actions mostly transparent, though identities of who voted what way should be eliminated via using a hash of a given email and the identity of those evaluating the email such that each evaluated email by a user would make use of a unique hash/email/user. I.e. it could be verified that a user had voted on an email, but not how they voted and only by knowing the user's subscription address (no way to obtain plaintext emails from a hash).

Stasiek Michalski

20:18

New subject: automation of Managing list offtopicness (was: Re: Managing list offtopicness better.)

Am 17. Dezember 2020 20:16:34 MEZ schrieb "Linda A. Walsh" :

...

Some initial comments on severity of penalties, and possible idea for automatically handling some problems....

On 2020/12/12 09:30, Per Jessen wrote:

...
If deemed appropriate, someone might have been banned for a while, or even for life.

Even in the case of murder, parole is possible depending on circumstances.

Are people committing offenses on this list such that lifetime banishment should even be considered? The idea that someone should be banned for life for anything consisting solely of a list post, seems entirely excessive.

Add them to a spam list that expires in a year, at most, but be reasonable. If they violate anything again, add them again, but realize a lifetime ban really encourages them getting one or more alternate email accounts from which they can easily snipe with impunity.

Even a year is a long time in the internet community -- and remember, once you've enacted such a penalty, you are done. There's not much else you can do to influence their behavior, with a "lifetime" ban essentially saying that there is no way "someone like them" can ever change, grow or correct their behavior.

I very explicitly asked the rest of the board to consider abolishing the lifetime ban entirely and move to timeout bans instead. It seems like we may have reached an agreement ;) This is something that we adopted very early on on Discord, and it has been working out really well for us, and I so I thought the rest of the community could benefit from it as well. I'm glad to see I'm not the only one

...

Also, I can't say this is true for everyone, but from personal experience, I've been subject to, maybe 3-4 bans, none of which was for valid cause when the original postings were examined. In at least 1-2 situations, the organization (or person) involved was made redundant, dissolved, shut-down or defunded due, most often, to similarly ill-handled situations.

Possible way to handle:

Personally, I'd try to develop an automated approach -- literally a Bayesian filter that could stop a posting before it is distributed and send the posting back to the user with comments like: "This posting looks like it might contain:" "offensive language", "offensive style", "minority marginalization", or "XXYZ". "If you are sure you wish to send this, please add a line at the end with the text:

Confirm post.

On a line by itself, within 5 lines of the end (the line will be removed before being passed onto the list)".

==== As part of the list-footer, give a non-clickable URL (need to cut+paste into a browser) with a unique messageID that leads to a page where list-members can add a vote regarding the post as to it most matching one of the banned topics (it may match more than one, but indicate only 1 topic that best fits the circumstance).

Votes would only be allowed to list members as verified by user-login by-email to a site, OR by sending an email from a list-user email with the email-ID of the email being evaluated+its category.

Note: categories could be positive areas as well for building up kudos or bonuses for a given topic.

Hyperkitty currently has a voting system as well as tags you can add from the web interface which are primarily useful for the search engine (it by default shows the most upvoted postings and searches by tags). Currently nobody uses that though, because I don't think many people appreciate how much it improves the searching experience long term ;)

...

==== Ratings for email-types would be built up over time with # of users out of #-readers marking a post as 'matching'. Evaluations would be limited to votes associated with 1 poster, at most, 'N' times (1 or 2?)/day per poster.

Blah blah blah....further design TBD as needed....

This way people can, AT FIRST, get preliminary feedback that what they are posting may be considered offensive. Depending on the strength of matched scores, and number of warning-overrides used, someone could be given an automatic cooldown period of "N" days or weeks (or months) -- which, ALSO, could be seen as a temporary 'posting ban' for that period.

The automation of this process would hopefully reduce or eliminate reactionary, vigilante, and/or emotional actions.

Preferably, the software would be open-sourced to allow other lists to use it as well as making "bot" actions mostly transparent, though identities of who voted what way should be eliminated via using a hash of a given email and the identity of those evaluating the email such that each evaluated email by a user would make use of a unique hash/email/user. I.e. it could be verified that a user had voted on an email, but not how they voted and only by knowing the user's subscription address (no way to obtain plaintext emails from a hash).

This does seem like it could be pretty problematic and in many respect only make the mailing list a bigger challenge than it really needs to be, but contributions to mailman, hyperkitty and postorius or a new project as an extension to mailman using its api are always welcome. We would consider deploying such a system if it existed and actually helped us solve issues, however as it stands it doesn't seem like people are very keen on using features already provided by hyperkitty to begin with, so I have serious doubts if this would make much of a difference. LCP [Stasiek] https://lcp.world/

Per Jessen

22 Dec 22 Dec

21:02

New subject: automation of Managing list offtopicness (was: Re: Managing list offtopicness better.)

Linda A. Walsh wrote:

...

Some initial comments on severity of penalties, and possible idea for automatically handling some problems....

On 2020/12/12 09:30, Per Jessen wrote:

...
If deemed appropriate, someone might have been banned for a while, or even for life.

Even in the case of murder, parole is possible depending on circumstances.

Are people committing offenses on this list such that lifetime banishment should even be considered? The idea that someone should be banned for life for anything consisting solely of a list post, seems entirely excessive.

Apologies for the late reply, it is that time of the year. To my knowledge noone has ever been banned for life for anything consisting solely of a list post. I know of two examples, both individuals were repeatedly asked to adjust their behaviour, yet they refused to relent.

...

Add them to a spam list that expires in a year, at most, but be reasonable. If they violate anything again, add them again, but realize a lifetime ban really encourages them getting one or more alternate email accounts from which they can easily snipe with impunity.

Linda, you have to appreciate how stretched our infrastructure team is. There is very little room to be nice. -- Per Jessen, Zürich (9.4°C) Member, openSUSE Heroes

Carlos E. R.

23 Dec 23 Dec

22:07

New subject: automation of Managing list offtopicness (was: Re: Managing list offtopicness better.)

On 17/12/2020 20.16, Linda A. Walsh wrote:

...

Some initial comments on severity of penalties, and possible idea for automatically handling some problems....

On 2020/12/12 09:30, Per Jessen wrote:

...
If deemed appropriate, someone might have been banned for a while, or even for life.

Even in the case of murder, parole is possible depending on circumstances.

Are people committing offenses on this list such that lifetime banishment should even be considered? The idea that someone should be banned for life for anything consisting solely of a list post, seems entirely excessive.

Not for a single post. I remember someone that was often insulting other people and had to be banned for life, because he would not relent. Someone else had the tourette syndrome and was asked to leave, I think. Foggy memories here. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

Simon Lees

13 Dec 13 Dec

07:21

On 12/13/20 12:25 AM, Adrien Glauser wrote:

...

There are few clear-cut and objective criteria for on-topic vs. off-topic. Putting people under moderation on the base of unclear, non-objective criteria might not the best of ideas if you want to build trust and healthy social interactions. Arbitrariness and biases will probably be lurking in about every corner.

...

Fortunately the on / off -topic is not the most relevant distinction you need to keep the MLs clean. If you need a middle-ground between (dangerously arbitrary, free-speech infringing) moderation and nice but sometimes insufficient abstract rules (such as the Code of Conduct), you can do 2 simple things:

Both these lists have reasonably well defined definitions of what is and isn't ontopic. In this instance we are more trying to put in a framework on how to handle people who are repeatedly taking these lists off topic. They will still be able to post, its just there posts will need to be approved to ensure they are not going offtopic. This isn't intending to target someone who posts something offtopic on a one off occasion because they are unaware of the rules, we always want to be open and friendly to new people. The second part is sometimes it is obviously clear that a one of post goes against our guiding principles in such cases by empowering a moderator to take action here the issue can be clearly and cleanly resolved far quicker and easier then if the board needs to be involved, especially if it occurs at a time when the board is sleeping etc.

...

1) Provide a clear path / resolution site for interpersonal conflicts and issues. For example if two people are going two far, you take them apart and iron things out, taming the fire before it spreads over other channels. 1 able person might suffice for doing that for not just the mailing lists but every oS channel. So that instead of punishing, you might end up creating a positive mindset for all parties.

This has and very much will continue to be the role of the board and very much describes the process we take to deal with such issues although it varies a little from instance. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Adrien Glauser

10:23

...

The MLs clearly define what is / is not offtopic Sorry Simon, they do not, and could not, because topicality is not the kind of concept that admits of a definition (in terms of individually necessary and jointly sufficient conditions). It'a concept that essentially depends on how someone interprets something in some context. Of course, you might try to *approximate* something like a universal definition -- until it runs into a counterexample and chokes.

To make explicit something implicit in my proposal above: there is a key difference between: - a flock of anonymous people being toxic on instant messaging channels; and - people who've known each other for weeks if not years and who have a propensity to knock each other's egos. Rubbing the latter under the brittle "on / offtopic" notion, and then adopting a "warn then mute" approach is losing a key opportunity to *actually solve the issue*. Instead the relational issue is just hidden and may come back stonger next time.

...

Involving the Board I am glad I nowehere implied that the idea of "treating the root cause of behavioural / relational issues" on the MLs or oS communication channels required the Board. You can have your "moderator" do the thing I am describing (helping two members overcome their animosity) and turn to the Board only if all other failsafes have failed. And it's probably for the better, since people from the Board are often -- from what I've observed -- involved in these problematic exchanges.

Now it occurs to me that the Board has already made a decision, so there is no point for me to argue against it. If the moderation team prioritizes the approach I am advocating over the lazy "warn and mute" solution, it can work. I hope it will.

Stasiek Michalski

12:20

Am So, 13. Dez, 2020 um 10:23 A. M. schrieb Adrien Glauser :

...

...
The MLs clearly define what is / is not offtopic Sorry Simon, they do not, and could not, because topicality is not the kind of concept that admits of a definition (in terms of individually necessary and jointly sufficient conditions). It'a concept that essentially depends on how someone interprets something in some context. Of course, you might try to *approximate* something like a universal definition -- until it runs into a counterexample and chokes.

To make explicit something implicit in my proposal above: there is a key difference between: - a flock of anonymous people being toxic on instant messaging channels; and - people who've known each other for weeks if not years and who have a propensity to knock each other's egos. Rubbing the latter under the brittle "on / offtopic" notion, and then adopting a "warn then mute" approach is losing a key opportunity to *actually solve the issue*. Instead the relational issue is just hidden and may come back stonger next time.

But we have users and offtopic mailing lists (and everyone has their private inbox!) to solve those issues without having to drag the whole list, which has wildly different default topic, with them. None of us are advocating just warning and muting anyone that sends a message slightly off topic, the role of moderators is to feel out the conversations and in case they are heading in a direction which isn't list appropriate (or just not appropriate in general), nudge the people to finish the conversation in a different place. The warning and mutes are tools for clear cut spam and guiding principles violations more than anything else. This is no different from people suggesting different channel on irc, telegram, discord, matrix for finishing up their conversation. I would assume that concept should be fairly well understood, since I see that done all the time in all 4 of those. Forums are slightly different since topics can be moved between the categories, and span multiple categories, so moderators do have the ability to act on topics after the fact of them being created and used.

...

...
Involving the Board I am glad I nowehere implied that the idea of "treating the root cause of behavioural / relational issues" on the MLs or oS communication channels required the Board. You can have your "moderator" do the thing I am describing (helping two members overcome their animosity) and turn to the Board only if all other failsafes have failed. And it's probably for the better, since people from the Board are often -- from what I've observed -- involved in these problematic exchanges.

That's very much not a good thing for an impartial body over conflicts ;) LCP [Stasiek] https://lcp.world

Adrien Glauser

12:44

...

nudge the people to finish the conversation in a different place That's precisely what I've described as a mistake above, namely the illusion that having people resolve their tensions elsewhere is doing them any good, or to the community, when they know each other by names. The more adequate answer is for this special case is: You sit with them and actively help them iron things out, because that's the most reliable of rebuilding trust between them. If that's the strategy behind Simon's message when he wrote users who regularly take the list off topic from now will be placed under moderation for a period of time. then it's all good. But seeing from your answer, I doubt it.

Stasiek Michalski

12:50

Am So, 13. Dez, 2020 um 12:44 P. M. schrieb Adrien Glauser :

...

...
nudge the people to finish the conversation in a different place That's precisely what I've described as a mistake above, namely the illusion that having people resolve their tensions elsewhere is doing them any good, or to the community, when they know each other by names. The more adequate answer is for this special case is: You sit with them and actively help them iron things out, because that's the most reliable of rebuilding trust between them.

Ah, well, users with tension between them are another topic entirely, and I agree, but then conflict resolution has even less value being on the lists than off of them. This is something that needs to be resolved separately and entirely out of the scope of this.

...

...
users who regularly take the list off topic from now will be placed under moderation for a period of time.

If that's the strategy behind Simon's message when he wrote then it's all good. But seeing from your answer, I doubt it.

That refers to the guiding principles violations that result from people going on irrelevant tangents ;) LCP [Stasiek] https://lcp.world

Adrien Glauser

13:44

>tension between is another topic entirely
That's the second thing I've described as a mistake above: the illusion that there is an issue of offtopicness on the MLs that deserves moderation in the sense of makint it justifies to turn to a warn then mute approach. There is none. What there are instead:
- offtopicsness, which does not make it justifies to turn to anything like a warn then mute approach, which is simply handled by participants, i.e. by responding to this or that message.
- behavioural / relation issues, which might justify turning to the warn then ban approach when all other failsafes have failed, but are often more fruitfully handled using the "pull them aside and help them iron things out" approach I am advocating.

Adrien Glauser

13:48

I apologize, I hit the "send" button too early. Here is what I wanted to say.

...

users with tension between them are another topic entirely

That's the second thing I've described as a mistake above: the illusion that there is an issue of offtopicness on the MLs that deserves moderation in the sense of makin it justifies to turn to a warn then mute approach. There is arguably none. What there arguably is instead: - offtopicsness, which never makes it justified to turn to anything like "a warn then mute approach", and is simply handled by participants, by not responding to this or that message; - behavioural / relation issues, which might justify turning to the "warn then ban approach" when all other failsafes have failed, but are often more fruitfully handled using the "pull them aside and help them iron things out" approach I am advocating.

Stasiek Michalski

14:32

Am So, 13. Dez, 2020 um 1:48 P. M. schrieb Adrien Glauser :

...

I apologize, I hit the "send" button too early.

Here is what I wanted to say.

...
users with tension between them are another topic entirely

That's the second thing I've described as a mistake above: the illusion that there is an issue of offtopicness on the MLs that deserves moderation in the sense of makin it justifies to turn to a warn then mute approach. There is arguably none. What there arguably is instead: - offtopicsness, which never makes it justified to turn to anything like "a warn then mute approach", and is simply handled by participants, by not responding to this or that message;

As presented by quite a lot of people over the span of the last few weeks, not responding is hard. Maybe having a moderator remind them that that's a possibility they can actually remove cc to a mailing list or add a cc to another mailing list will be valuable. Not to mention, describing moderation and muting isn't accurate considering their mails are placed in a queue of mails to be approved by the moderators.

...

- behavioural / relation issues, which might justify turning to the "warn then ban approach" when all other failsafes have failed, but are often more fruitfully handled using the "pull them aside and help them iron things out" approach I am advocating.

That's the function of the board, not the moderators, and completely irrelevant to the topic, maybe we should discuss that off list ;) LCP [Stasiek] https://lcp.world

Adrien Glauser

14:44

...

Let's go off list To me the fact that someone insists on treating issues separately when someone else insists on treating them jointly is testimony that basing *moderation* on *offtopicness* is indulging in a conceptual mistake. I'll stop there though, as I think the argument I've put forth is now clear.