Real Name was:Re: Testing Discourse for Debian
On April 14, 2020 11:12:10 PM UTC, Sean Whitton wrote: >Hello Raphael, > >On Tue 14 Apr 2020 at 12:28PM +02, Raphael Hertzog wrote: ... > >> He was also concerned with the need to do all work under our real >> identity. Looking into contributors.d.o and db.debian.org, he might >> have requested his data to be dropped... > >This is a separate issue, surely -- mailing lists do not inherently >require you to use your real name. We don't actually have a requirement for that in any case. We require someone in the project know who you are (which I think is a definite minimum standard we need to maintain), but there is a process for becoming a member of the project without publicly disclosing your identity. For non-members whose contributions are sponsored, we have no requirement even for that. Scott K
Re: Testing Discourse for Debian
Hello Raphael, On Tue 14 Apr 2020 at 12:28PM +02, Raphael Hertzog wrote: > I remember a discussion with Ryan Murray (who was very involved a long > time ago!) and he expressed concerns over our use of email and > GPG. And the fact that you must share your email to everybody to be > able to take part into conversations (in particular given how this > leads to spam). We share e-mail addresses in changelogs and git commit messages, so I don't think we're going to be able to do anything about this any time soon. > He was also concerned with the need to do all work under our real > identity. Looking into contributors.d.o and db.debian.org, he might > have requested his data to be dropped... This is a separate issue, surely -- mailing lists do not inherently require you to use your real name. -- Sean Whitton signature.asc Description: PGP signature
Re: Testing Discourse for Debian
Hello, On Tue 14 Apr 2020 at 01:49PM +01, Neil McGovern wrote: > On Mon, Apr 13, 2020 at 02:16:48PM -0700, Sean Whitton wrote: >> Do you think that would end up capturing all discussions, with possibly >> a few weeks delay? Is it typical in Discourse use to lock/close threads >> after a certain point? And do you think the API is stable enough for us >> to start doing something like this? >> > > That's entirely dependant on the configuration :) For example, on > GNOME's Discourse instance, I have a few categories where it is set to > close 14 days after the last reply. > > Then again, people can also request that they're reopened... > > I suspect the API should be stable enough for this, if people wanted to > store discussions in a form that isn't discourse itself. Based on other posts in the thread it sounds like the API is not actually stable enough to support this sort of thing, but of course that could change. It sounds like we would need to disable the unlocking functionality you mention in order for offline longterm storage to be feasible. To be honest, the lack of any proper archival means that I am reluctant to start any meaningful discussions on the test instance you've set up, but then it is rather difficult to test whether it's a good platform for us to have meaningful discussions... Is it perhaps possible for us to subscribe a mailing list to all posts from the instance, so that we know that there's a copy somewhere? On Tue 14 Apr 2020 at 05:17PM +02, Martin wrote: > On 2020-04-14 15:49, Neil McGovern wrote: >> If you're using the stable branch of Discourse, then the API is stable >> :) > > Ha! ;-) This leads a little bit off-topic here, maybe it's > better off-list, on #956705, or elsewhere: > > Can I expect API stability cycles of Discourse long enough, that > it were practical to have a client (library) in stable? If others share my concerns about posterity then it is not off-topic. -- Sean Whitton signature.asc Description: PGP signature
Re: [Summary] Discourse for Debian
On April 14, 2020 9:42:33 PM UTC, Sam Hartman wrote: >> "Ihor" == Ihor Antonov writes: > > > >Ihor> I want to leave this as is without final verdict. Everyone >Ihor> should make their own. > >I really appreciate the idea of summarizing the thread; I agree with >you >it has gotten long. > >A good summary is one where people on all sides of the issue will look >at the summary and say that yes, that looks good. > >I strongly suspect you've missed there. >I think more of your personal bias comes through into this summary >than >would be ideal. > >Also, for each item, you put it in one category, even when some people >think it is a pro and some people think it is a con. > > >So, I think that the approach you're going for--summarize the >discussion >and see where we stand--is good, >it would be valuable to try and paint things in a much less biased way >so that: > >* People who said things look at your summary and say "that's what I > said" > >* People who disagree with those things look at your summary and say > "yep, my disagreement is represented." Sam, I think you've missed the mark here, except perhaps the why another service section at the end. Personally I'm in the "I think it's unsuitable for Debian" camp and I see my concerns represented. I also see several items where I agree it's a claimed advantage, but I don't think it really is. No summary is perfect. I think this one is pretty good (even the parts I disagree with - it does summarize the discussion). Scott K
Re: tracking our readers? (Re: Testing Discourse for Debian - Moderation concepts)
Hello Karsten, On Tue 14 Apr 2020 at 06:42PM +02, Karsten Merker wrote: > As a personal note: compared to my email client I find the > discourse web interface very unwieldly and impractical (like most > web forums). This is of course a matter of taste and personal > preferences, but exactly that is an important point. With > mailinglists everybody can use a client that suits one's personal > preferences, while web-based systems inevitably force a > particular user interface onto every user. This one interface > naturally cannot fit everbody's personal preferences and > therefore makes the task of following and taking part in > discussions actually harder for a significant number of people > compared to performing the same tasks on a mailinglist. Just on this point, if there's sufficient API stability, then there is the possibility of developing other clients for Discourse. Making them operable offline would be a lot of work though. -- Sean Whitton signature.asc Description: PGP signature
Re: Testing Discourse for Debian
Hello Andrei, On Tue 14 Apr 2020 at 09:21AM +03, Andrei POPESCU wrote: > On Lu, 13 apr 20, 14:23:30, Sean Whitton wrote: >> >> (a) would more clearly benefit from having more structure. It is less >> clear that (b) would benefit, and (b) benefits from the posting of diffs >> and replying using inline comments. > > It seems like Salsa would be better suited for commenting on actual > code, though splitting the discussion is obviously not be optimal. That has the problem of it being difficult to archive those discussions for posterity. -- Sean Whitton signature.asc Description: PGP signature
Re: tracking our readers? (Re: Testing Discourse for Debian - Moderation concepts)
Hello, On Tue 14 Apr 2020 at 08:22AM +00, Holger Levsen wrote: > On Mon, Apr 13, 2020 at 02:31:23PM -0700, Sean Whitton wrote: >> > The trust system gives me no trust at all. It is very closely bound to >> > participation over the web interface, monitors the reading frequency and >> > time >> > spent on reading by users. >> [1] >> https://meta.discourse.org/t/how-does-post-tracking-work-in-discourse/115790 > > thanks for pointing this out, Sean. This makes even using discourse > inaccepable to me, sorry. > > I also wonder where we will store this private data of our users, how > we will protect it and how users can request their data to be deleted. Just a note that the text Holger quoted is from Mathias Behrle's e-mail, not mine -- and he should have credit for having noticed this. I just Googled a bit. -- Sean Whitton signature.asc Description: PGP signature
Re: Draft Delegation for the Community Team
Absolutely, the DPL, or DAM, or others may forward to the CT. That would count as it being directed their way.
Re: [Summary] Discourse for Debian
On Tue, Apr 14, 2020 at 3:48 PM Sam Hartman wrote: > > > "Ihor" == Ihor Antonov writes: > > > > Ihor> I want to leave this as is without final verdict. Everyone > Ihor> should make their own. > > I really appreciate the idea of summarizing the thread; I agree with you > it has gotten long. > > A good summary is one where people on all sides of the issue will look > at the summary and say that yes, that looks good. > > I strongly suspect you've missed there. > I think more of your personal bias comes through into this summary than > would be ideal. Hi Sam, It would probably be more helpful to make concrete content suggestions than to simply state that you don't think he did a good job of summarizing. I think Ihor's summary very helpful, and he invited comments if people disagree or think he missed something. He obviously spent a lot of time reading the threads, and I think your comment came off a lot more negatively than you intended. -- Eldon
Re: Draft Delegation for the Community Team
TL;DR: As Tina points out, this delegation does not accomplish everything. It is an incremental step forward, one of many we've taken this last year. Tina brings up a number of points where there might be value in revising text if we get the support to do so. I welcome such proposals for improvement both before and after the delegation is made. I am not seeing blockers here--I think that the delegation is enough of a step forward over the status quo. But I think that it is worth continuing the process of incremental improvement even after the initial delegation is made. > "Martina" == Martina Ferrari writes: Martina> It seems to me that this delegation text does not improve Martina> the situation of the Community Team compared to the current Martina> non-delegated team. I do not think it serves the actual Martina> needs of the project, My understanding is that the DPL, Community Team, and Account Managers all believe it will help the project for the Community Team to be delegated. Moreover, we had a fairly comprehensive discussion back last summer after DebConf. Steve lead that discussion and solicited feedback from the project on the CT's mission and what it would like to do. The feedback from the project was that the project would like to see a delegation for a number of the items in that mission. My reading of that discussion is that there was broad support for a delegated CT performing the mission that the CT proposed for itself. There were a few other items where things got revised in response to feedback. But this delegation is very much a follow on to that earlier discussion. The CT solicited feedback from the project. Later, after the CT grew a bit, and honestly, after some circumstances allowed us to experience first-hand why a CT is valuable, the DPL and CT got together to confirm we'd taken that project feedback into account and move to the next step. Martina> nor that it will help address the Martina> problems that have caused burnout and high turnover rates. I think there are two different approaches in play to adress burn-out and high-turn over rates. Steve talked to you about one of them: by having a larger team and by working on some internal processes he hopes to reduce this. In parallel, this delegation expresses the importance of the DPL and CT working together on ongoing recruitment. I think it will be great if Steve succeeds with his plan. However looking at what I know of other organizations where I understand how the CT/antiharassment processes work, high turnover is inherent. So, I think that recruiting may also be important. Together I have confidence that these two approaches will help move us forward. Martina> * All of the activities of the CT seem subordinated to the Martina> interest and willingness of other parties to work with them Martina> and listen to their advice. No provision is made for when Martina> this is not the case. Ever since I've been tracking the CT, this has been the case. The first etherpad you showed me about what the CT hoped it would do--back when I was a trainee on the antiharassment team--contained language talking about how the antiharassment team didn't have power to enforce decisions. That's consistent with the feedback the project was giving the AH team on debian-private and debian-project back in 2019. It's possible that before the events of December 2018, the antiharassment team had a different vision. But certainly by the time I started to see that vision--certainly well before I started to influence that decision except as a individual project member, things were consistent with what you quote above. If the CT is not able to do what it needs to do because of a conflict with another team, the CT can come to the DPL and/or the project, just like anyone else. It's absolutely true that dealing better with such conflicts is an area where Debian could improve overall. Delegating the team is a project/DPL commitment to help the team succeed. We're saying this is important enough work that we want to put in the resources and resolve conflicts that come up. Martina> * In particular, Debian events are not required to do Martina> anything. This can result in big events going ahead without Martina> any kind of support for on-site conduct issues, as it was Martina> almost the case for DebConf19 (when the CT noticed the Martina> omission just before DC started). I don't want to hold up the delegation to resolve this. However, I agree with you this could be improved. The current wording reflects the mission the CT wanted to take on. I would support discussion of how we can get a stronger incident response component in our events. I don't think we'll come to conclusions in my term as DPL, but I think it would be easy to update the CT delegation and potentially other delegations based on that discussion. Martina> How is the team going to make that
Re: [Summary] Discourse for Debian
> "Ihor" == Ihor Antonov writes: Ihor> I want to leave this as is without final verdict. Everyone Ihor> should make their own. I really appreciate the idea of summarizing the thread; I agree with you it has gotten long. A good summary is one where people on all sides of the issue will look at the summary and say that yes, that looks good. I strongly suspect you've missed there. I think more of your personal bias comes through into this summary than would be ideal. Also, for each item, you put it in one category, even when some people think it is a pro and some people think it is a con. So, I think that the approach you're going for--summarize the discussion and see where we stand--is good, it would be valuable to try and paint things in a much less biased way so that: * People who said things look at your summary and say "that's what I said" * People who disagree with those things look at your summary and say "yep, my disagreement is represented."
Upcoming stable point release (10.4)
Hi, The next point release for "buster" (10.4) is scheduled for Saturday, May 9th. Processing of new uploads into buster-proposed-updates will be frozen during the preceding weekend. Regards, Adam
Re: Draft Delegation for the Community Team
Le 13/04/2020 à 17:19, Sam Hartman a écrit : AS I understand it the only open issue preventing a delegation is the following; we need to find wording that makes it clear you can write to parties other than the CT. >> * To respond to concerns raised by members of the project or >> people interacting with them, working with individuals to help >> them. my intent was that if you write to the DPL, the DPL responds. If you write to the CT, the CT responds. If you write to both, they cooperate. I agree the above bullet doesn't say that; good catch on your part. How about: * To respond to concerns directed to the Community Team, raised by members of the project or people interacting with them, working with individuals to help them. ack for me too. In practical I think the DPL may forward some request to CT, if the requestor agrees, to avoid burnout and start cooperate. Best regards I need an ack from at least one member of the CT, a NACK from any member of the CT will be blocking, and of course comments from the larger community are welcome. If I get an ACK and no other blocking issues come up, my next step is to delegate.
[Summary] Discourse for Debian
The thread about Discourse is getting too long (both in user and project lists) and a lot of people's reactions start to repeat. So I just wanted to summarize so far everything that people have stated so far in a concise manner, and I invite everyone to complete this pros/cons list. (items are in no particular order) pros: = - easier moderation (for moderators) - attracts people who are not comfortable with email - easier +1 for polls - easier to split threads - search function returns relevant results - ability to close threads - auto-summarize feature - supposed to attract younger audience cons: = usability: -- - does not work offline - does not work without graphical environment - does not really work outside of the web browser - does not work work without javascript - Not 100% GPL - some javascript scripts loaded into users browser are not free - moderation abilities exclusively tied to web interface - makes it harder to use for people with limited abilities - makes it harder to use on weak or non-mainstream hardware that can't run modern web-browser - email integration is second-class, including poor support for quoting - requires login - hard to enter long texts due to imperfect web interface - achievements/badges/other gamification of the process - increased context switching (instead of all mail from many projects in one inbox need to visit multiple different websites and your email mailbox anyway) - trust levels are revoked if you don't use web interface often enough to maintain current trust level - learning curve exists and so it forces existing users to learn new tool privacy: - tracks user activity (including time spent on each page/topic) - currently no way to request removal of collected user's data - "trust levels" are earned by spending time on the website and increasing post counts allow gaining moderation capabilities - distributed moderation based on trust levels (amplified by points below) - moderation possibilities allow editing messages of others - 1-to-1 messages are not really private (with email it is direct mta-to-mta vs discourse still is a middleman) - moderation audit log is supposed to be present by I have not found it. - "ease of moderation" is not received positively by end users why yet another tool/service? - - yet another service splits the community - there is already http://forums.debian.net - there is already https://reddit.com/r/debian - similar efforts have failed int the past due to lack of interest to web browser services (shapado.debian.net / ask.debian.net) I want to leave this as is without final verdict. Everyone should make their own. -- Ihor Antonov https://useplaintext.email
Re: Draft Delegation for the Community Team
Hi Sledge, On 14/04/2020 16:03, Steve McIntyre wrote: > I hope you're keeping well in these difficult times... *hugs* I am doing fine, thanks. I wish the same for you and your family! >> It seems to me that this delegation text does not improve the >> situation of the Community Team compared to the current non-delegated >> team. I do not think it serves the actual needs of the project, nor >> that it will help address the problems that have caused burnout and >> high turnover rates. > > In the team we're happy enough with what's here. It's not seeking to > redefine the role, but more to describe what we've already been doing > and make it more official. Our own work to improve processes and grow > the team should help to reduce the burnout problem. I am not privy to the internal discussions that led to this, but from my now external perspective, combined with my past experience, I see it as a step backwards compared to what the team was aiming to be a couple of years ago. >> * In particular, Debian events are not required to do anything. This >> can result in big events going ahead without any kind of support for >> on-site conduct issues, as it was almost the case for DebConf19 (when >> the CT noticed the omission just before DC started). > > A delegation for the CT can't *force* event organisers to do anything, > but making us official should help to raise visibility. What else > would you suggest? No, but it could very well automatically give responsibilities to the team for Debian-branded events, or could at least enunciate expectations regarding this topic. Plus, it only mentions "concerns" as the role of incident response teams, which sounds a bit like a complaints book on a table. >> * It mandates the team to coordinate responses, but my experience >> shows that other teams -such as DAM or the DPL itself- do not always >> collaborate when discussions get heated and coordination is most needed. >> >> How is the team going to make that coordination happen? How is it >> going to prevent burning out people when they are left alone to face >> the angry mob? > Mainly by not leaving them alone. That's been a problem in the past, > and it's a mistake we don't want to make again. The problem is that I don't see that either in the letter or the spirit of the text. >> * At a first glance the people chosen do not seem to reflect the >> diversity of our project, which is of tremendous importance when >> dealing with cultural conflicts. The DPL has stressed repeatedly the >> need to find "the right people for the job", but I am still curious >> about the criteria. >> >> The less-than-transparent way personnel changes have been handled >> lately, combined with this apparent lack of diversity in the team that >> has been finally blessed by the DPL is not a great look, IMHO. > Fundamentally, we have the team we have today; this specific > delegation is for the 5 current full members, all volunteers. As you > know from discussions we've had in the past, we care *very* much about > diversity and we're going to continue to work on improving the team in > that way. One previous member of the old A-H team is looking to rejoin > us very shortly, and we have another new volunteer who is going > through the onboarding process with us right now. Oh, I don't doubt for a moment the good intentions of the team members! I am sorry I did not word this properly, but please believe me that I don't intend any part of this complaint to be directed at the members of the team, specially when I have not interacted much with most of the current memnbers. My complaint is at the incoherence of statements made by the DPL about personnel selection and the lack of transparency about the criteria. >> In conclusion, I do not think this delegation is going to be effective >> in helping the CT become a sustainable and useful vehicle to better >> our community. > > Thanks for your feedback. Hope it is useful and that results in improvements to the draft and our processes. Tina.
Re: Testing Discourse for Debian
On 2020-04-14 15:49, Neil McGovern wrote: > If you're using the stable branch of Discourse, then the API is stable > :) Ha! ;-) This leads a little bit off-topic here, maybe it's better off-list, on #956705, or elsewhere: Can I expect API stability cycles of Discourse long enough, that it were practical to have a client (library) in stable? I'm not talking about one site running on nightlies, but something serious, e.g. the Gnome instance. > The documentation is at > docs.discourse.org. Nothing shown by default, but when I unblock CDNs, there is a long "Loading...", then "A script on this page may be busy, or it may have stopped responding", but finally a download link: https://docs.discourse.org/swagger.json In which I read: > Note: This documentation is not complete, so for missing parts > you may have to\n[reverse engineer the Discourse API](https:// > meta.discourse.org/t/how-to-reverse-engineer-the-discourse-api > /20576) to figure out how to use an API endpoint. My fear is, that an un(der)documented API might also not be long-term stable, even if such a disclaimer is not present.
Re: Draft Delegation for the Community Team
Hey Tina! I hope you're keeping well in these difficult times... *hugs* On Tue, Apr 14, 2020 at 07:14:01AM +0100, Martina Ferrari wrote: >On 09/04/2020 22:40, Sam Hartman wrote:> I'm pleased to finally be >able to propose a Community Team delegation >> for discussion. During the last year it has become clear that we >> can accomplish more at lower emotional cost when we have the >> Community Team, Account Managers and DPL working together, >> supporting each other. It's become clear that the Community Team >> does need a project-level mission/mandate. > >It seems to me that this delegation text does not improve the >situation of the Community Team compared to the current non-delegated >team. I do not think it serves the actual needs of the project, nor >that it will help address the problems that have caused burnout and >high turnover rates. In the team we're happy enough with what's here. It's not seeking to redefine the role, but more to describe what we've already been doing and make it more official. Our own work to improve processes and grow the team should help to reduce the burnout problem. >* All of the activities of the CT seem subordinated to the interest >and willingness of other parties to work with them and listen to their >advice. No provision is made for when this is not the case. > >* In particular, Debian events are not required to do anything. This >can result in big events going ahead without any kind of support for >on-site conduct issues, as it was almost the case for DebConf19 (when >the CT noticed the omission just before DC started). A delegation for the CT can't *force* event organisers to do anything, but making us official should help to raise visibility. What else would you suggest? >* It mandates the team to coordinate responses, but my experience >shows that other teams -such as DAM or the DPL itself- do not always >collaborate when discussions get heated and coordination is most needed. > >How is the team going to make that coordination happen? How is it >going to prevent burning out people when they are left alone to face >the angry mob? Mainly by not leaving them alone. That's been a problem in the past, and it's a mistake we don't want to make again. ... >* At a first glance the people chosen do not seem to reflect the >diversity of our project, which is of tremendous importance when >dealing with cultural conflicts. The DPL has stressed repeatedly the >need to find "the right people for the job", but I am still curious >about the criteria. > >The less-than-transparent way personnel changes have been handled >lately, combined with this apparent lack of diversity in the team that >has been finally blessed by the DPL is not a great look, IMHO. Fundamentally, we have the team we have today; this specific delegation is for the 5 current full members, all volunteers. As you know from discussions we've had in the past, we care *very* much about diversity and we're going to continue to work on improving the team in that way. One previous member of the old A-H team is looking to rejoin us very shortly, and we have another new volunteer who is going through the onboarding process with us right now. >In conclusion, I do not think this delegation is going to be effective >in helping the CT become a sustainable and useful vehicle to better >our community. Thanks for your feedback. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall
Re: Testing Discourse for Debian
On Tue, Apr 14, 2020 at 03:57:08PM +0200, Martin wrote: > Is the API stable in general, or only this particular function? If you're using the stable branch of Discourse, then the API is stable :) > I ask in the context of #956705: "ITP: python-pydiscourse -- > Python library for working with Discourse". Upstream says: > > > * Provide functional parity with the Discourse API, for the > > currently supported version of Discourse (something of a > > moving target) > > > > The order here is important. The Discourse API is itself > > poorly documented > The head version is indeed in flux somewhat, although I'm personally running the "tests-passed" branch in production with API integrations, and I've not had any incompatability problems. The documentation is at docs.discourse.org. I woudn't say it's poorly documented, but possibly incomplete. Neil -- signature.asc Description: PGP signature
Re: Testing Discourse for Debian - Moderation concepts
I'd like to echo the comment that requiring people to regularly visit the site does not seem to meet Debian's needs very well for trust. I'd imagine there are a number of people in our community who will tend to read things via email, but who would only visit the site to help moderate--splitting topics, editing things, flagging posts, etc. You can like a post via email. I think it is great to try new things. But I think that biasing the moderation power too much toward people who visit the website would make me uncomfortable trusting the system for important project discussions in ways that a system that allowed all our trusted users to be trusted would not. I absolutely think it is reasonable to require people to become familiar with the site and its capabilities. I think it is reasonable to expect trusted members to understand how this is different from traditional email. But forcing a particular interface on those people seems problematic. From my personal standpoint, the site isn't horrible from an accessibility standpoint, but reading what I can out of email is always going to be more usable for me. I'll go to the site if I need to, but being forced to go to the site to meet some metric is off-pissing. I'm not saying this needs to be addressed prior to experimenting. I'm saying that as an individual I want to see an improvement here prior to depending on this for any important project decisions. --Sam
Re: Testing Discourse for Debian
In order to improve the communication methods, the question is, if aspired improvements could be implemented for the email lists or not. If they cannot be implemented for the email lists, then improvements are unlikely to ever happen unless moving on to another communication platform where the improvements are possible. The very good things already achieved by email lists are: (1) messages cannot be changed with retrospective effect; all discussions stay well documented (2) the structured view in threads and various search options, as usually provided by the mail clients, help to effectively manage the vast amount of messages The things which need improvement are the messages themselves: (3) quality over quantity (4) more feedback without unnecessarily texting To this regard, addressing (3) and (4) at the same time by the same measure, various platforms introduced a scoring system for messages by analyzing the explicitly provided reader's feedback about the quality of messages and also building up a reputation score for the author. If the scoring algorithm is well selected, then an improvement of communication is indeed achieved by steadily stimulating the community to please not shine through by the number of comments but to instead search for satisfying reputation by considerably adding information to the topics. Now, could the feedback be collected by a mailing list, and could each message come accompanied by some reputation score? I doubt so. If the list server would add a score to the mail subject, then the email client would no more be able to view messages threaded, and if the score is not added there, then the user will not have the score information available at a glance. But without the score, no improvement of the communication is systematically stimulated. Could Discord (or other contenders) achieve this? Concerns (3) and (4) are addressed at the push of a button by what you could call an "Upvote", "Like", "Helpful", or alike feedback mechanism. Concern (2) is addressed for the web interface, and an email interface seems to be available for those who prefer this and could accept to stay without the steady reputation stimulus. Could Discord (or other contenders) achieve (1) ? I don't know. In my opinion an improvement in communication would result from a reputation generating scoring system, IF relying on an algorithm tuned for quality in community participation. The default Trust Levels as offered by Discourse are tuned for the opposite! They do not only rate higher the amount of participation, the frequency of input from chatterers, than the quality of participation, but even assign to members with a higher score the right to edit the messages of others! This violates above mentioned point (1) unless there would be a possibility to reliably configure this towards the real needs of Debian. The same need for a strongly adopted configuration targets the absurd and ludicrous default set of "badges". I suggest to have only one required badge available, and this to always overlay to the avatar in order to be visible at a glance for each single message displayed in the web interface: the score for the “Likes:Post ratio” (or something similar pointing towards a quality:quantity ratio of a member’s posts). The scoring algorithm could produce the integer numbers 0 to 9, normalizing to the member with the best ratio receiving a 9, and in general only placing a score number if the member has posted already 20 posts. If in a rush browsing for some fast help to a problem and not out for reading seesaw discussions about the preferences in the personal workflow of some individuals, then I would find some kind of guide in it for where it might be worth to start or stop reading a thread. Finally I could honor the seminal messages by myself providing my feedback at a push of a button. It would be helpful if a member "A" is limited to not honor more than 20 messages of a member "B" in order to prevent bias from personal friendships, and it would be great if reputation scores could be calculated for each topical channel individually. But trust levels which allow for editing posts are VERY problematic, especially in the Debian community! Maybe allow to the original editor of a post to correct its post in a short time window AND as long as no reply was posted - for correcting of typos and alike. But beyond this I doubt that giving somebody the possibility to edit a post - even if in practice never becoming used - would destroy confidence in the medium for discussing issues. The already difficult mixture of characters making up Debian would not receive help by using such medium, but would divide even more, if someone could impute message editing to some other person. If Discourse could be configured towards these ideas, then it would be a win for the communication, if not then it would simply be another platform but not an improvement
Re: Testing Discourse for Debian
On 2020-04-14 13:49, Neil McGovern wrote: > I suspect the API should be stable enough for this, if people wanted to > store discussions in a form that isn't discourse itself. Is the API stable in general, or only this particular function? I ask in the context of #956705: "ITP: python-pydiscourse -- Python library for working with Discourse". Upstream says: > * Provide functional parity with the Discourse API, for the > currently supported version of Discourse (something of a > moving target) > > The order here is important. The Discourse API is itself > poorly documented Maybe the README is just outdated.
Re: Discourse usability
On 2020-04-13 22:23, Martin wrote: > My personal and preliminary résumé is: "Something like Discourse would > be great, but maybe better something else, esp. w/o gamification?" I have been hinted, that this résumé sounds more negative than I actually meant it. Elsewhere on -project, I expressed an idea, that might be more constructive: On 2020-04-14 15:14, Martin wrote: > Maybe somebody™ can write a Discourse client? "Discurses"? > Something that downloads messages, supports offline reading, > answering, editing, "likes" and votes, and uploading results. Good: This might be interesting to other discourse users, too. Bad: Ideas are inexpensive, but I have neither the time nor the skills to implement such a client. Cheers
Re: Testing Discourse for Debian - Moderation concepts
On 2020-04-14 14:30, Ansgar wrote: > That said I'm in principle fine with trying a mostly > web-only system; just like GitLab also really needs to be used over the > web. I'm a salsa.d.o user of course, but how often would I login into the web interface? Once a month? 99 % of the interaction is git push and fetch. I'm happy, that we moved from svn to git, partly because I can do more things offline. While I'm in favour to explore alternatives to email, I don't feel comfortable with anything, that does not support offline usage and that does not work well on the text console. Maybe somebody™ can write a Discourse client? "Discurses"? Something that downloads messages, supports offline reading, answering, editing, "likes" and votes, and uploading results.
Re: Testing Discourse for Debian
On Mon, Apr 13, 2020 at 02:16:48PM -0700, Sean Whitton wrote: > Do you think that would end up capturing all discussions, with possibly > a few weeks delay? Is it typical in Discourse use to lock/close threads > after a certain point? And do you think the API is stable enough for us > to start doing something like this? > That's entirely dependant on the configuration :) For example, on GNOME's Discourse instance, I have a few categories where it is set to close 14 days after the last reply. Then again, people can also request that they're reopened... I suspect the API should be stable enough for this, if people wanted to store discussions in a form that isn't discourse itself. Neil signature.asc Description: PGP signature
Re: Testing Discourse for Debian - Moderation concepts
On Mon, 2020-04-13 at 19:56 +0100, Neil McGovern wrote: > Instead of explaining it here, please have a > read of the following: > https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/ > The short version is that the more a particular account interacts with > the community in a positive way, the more trust the system has about > them, and the more privileges they are afforded to assist in > moderation. I think some features of Discourse can be useful, for example moving messages to new topic, simple polls (I don't like "like" buttons...), or even editing messages to make the wording clearer instead of sending further follow-up messages. Trying to experiment with Discourse for this seems useful to me. The "trust levels" though are one of the features that I don't like: in particular "Trust Level 3 - Regular" mostly requires to constantly visit the site every day (or every other day), read x% of all posts and topics (even though they might not be relevant to your interest or in a foreign language you don't speak), ... to not get demoted again. It feels more like a customer loyality program to try to bind users to the Discourse service, like rewards for daily visits in mobile games, not anything that implies trust to somehow govern the system. The system also requires tracking active read time and such; I don't really like a system doing that... The notifications to welcome new people or that the system hasn't seem someone for some time[1] also seem designed to manipulate people into spending more time on the system. Such psychological tricks are something I would more expect from Facebook than Debian :-/ [1]: https://discourse.debian.net/t/likes-per-post-ratio/152/2 The claim of Discourse having an excellent email interface also feels exagerrated: unless I missed something[2] it seems very basic. One can send and receive messages, but quoting in replies already doesn't work as usual and any additional functionality isn't exposed at all as far as I can tell. That said I'm in principle fine with trying a mostly web-only system; just like GitLab also really needs to be used over the web. [2]: I couldn't really find much Discourse documentation, even less than for other things in Debian people say are underdocumented. > Instead, it encourages community members to flag posts. If a post receives > sufficient flags, it is then automatically hidden. Users may chose to > "unhide" the post for themseleves if they wish to view it. > > These are then sent to the moderating team to agree, disagree or > ignore the flag. What decides who is in the moderation team? That seems to be something different from the trust levels? I would also expect Discourse to have some way to entirely remove messages, or at least remove the original content fully and replace it with a notice that the message was removed; who can do that? Also the moderation team? Ansgar
Re: Testing Discourse for Debian - Moderation concepts
On Tuesday, April 14, 2020 06:09:48 AM Dan Purgert wrote: > On Apr 14, 2020, to...@tuxteam.de wrote: ... > > This is just the ultra-liberal way to see things. He who owns the > > resources has absolute say on their use. > > "ultra-liberal" -- I don't think that word means what you think it means > > :). As this veers wildly off topic, would you mind explaining this to > > me off-list? I'm interested as well, can it be posted on-list, the subject changed, and be marked OT?
Re: Testing Discourse for Debian - Moderation concepts
On 2020-04-13 23:33, Andy Smith wrote: > Not to speak for Neil, but it's generally argued that private > entities cannot censor, because a nation/state can tell you that you > cannot express an opinion using your own resources. By contrast a > private entity like Debian can only tell you that you cannot express > that opinion using *Debian's* resources: Debian can't prevent you > from publishing it independently, So Debian can't, under this line > of argument, censor you. That's a very strict interpretation that, even though technically possibly correct from a very specific human rights point-of-view, doesn't really match the general, real-world use of the term. For example, the concept of self-censorship clearly exists (eg: film industry), but wouldn't under the above strict interpretation. To emphasize the real-world use of the term, I point to the Wikipedia page for the term [1], which states in its first paragraph that "Censorship can be conducted by governments, private institutions, and corporations." [1] https://en.wikipedia.org/wiki/Censorship
Re: Testing Discourse for Debian
On Mon, 13 Apr 2020, Steve McIntyre wrote: > Hell, there's a strong confirmation bias here too - how many > potentially great future developers have we lost at a very early stage > because our email-centric workflow didn't appeal to them initially? We already lost existing Debian developers due to this. I remember a discussion with Ryan Murray (who was very involved a long time ago!) and he expressed concerns over our use of email and GPG. And the fact that you must share your email to everybody to be able to take part into conversations (in particular given how this leads to spam). He was also concerned with the need to do all work under our real identity. Looking into contributors.d.o and db.debian.org, he might have requested his data to be dropped... Email mailing lists are driving some people away. It's a fact. Web forum discussions are also driving some people away. I'm an email guy too, but I find discourse really interesting and I'm ready to give it a try (even if I'm above 40!). Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Re: Testing Discourse for Debian - Moderation concepts
On Apr 14, 2020, to...@tuxteam.de wrote: > On Mon, Apr 13, 2020 at 09:33:20PM +, Andy Smith wrote: > > [...] > > > Not to speak for Neil, but it's generally argued that private > > entities cannot censor, because a nation/state can tell you that you > > cannot express an opinion using your own resources. By contrast a > > private entity like Debian can only tell you that you cannot express > > that opinion using *Debian's* resources [...] > > This is just the ultra-liberal way to see things. He who owns the > resources has absolute say on their use. "ultra-liberal" -- I don't think that word means what you think it means :). As this veers wildly off topic, would you mind explaining this to me off-list? -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281 signature.asc Description: PGP signature
Re: tracking our readers? (Re: Testing Discourse for Debian - Moderation concepts)
On Apr 14, 2020, Holger Levsen wrote: > On Mon, Apr 13, 2020 at 02:31:23PM -0700, Sean Whitton wrote: > > > The trust system gives me no trust at all. It is very closely bound to > > > participation over the web interface, monitors the reading frequency and > > > time > > > spent on reading by users. > > [1] > > https://meta.discourse.org/t/how-does-post-tracking-work-in-discourse/115790 > > thanks for pointing this out, Sean. This makes even using discourse > inaccepable to me, sorry. > > I also wonder where we will store this private data of our users, how > we will protect it and how users can request their data to be deleted. The only correct answer is /dev/null. -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281 signature.asc Description: PGP signature
Re: Testing Discourse for Debian - Moderation concepts
On Lu, 13 apr 20, 19:56:28, Neil McGovern wrote: > > Firstly, trust levels. These are the levels of "trust" that the platform > has in any particular user. Instead of explaining it here, please have a > read of the following: > https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/ > The short version is that the more a particular account interacts with > the community in a positive way, the more trust the system has about > them, and the more privileges they are afforded to assist in > moderation. How do trust levels work for users interacting mainly (or even exclusively) via mail? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: tracking our readers? (Re: Testing Discourse for Debian - Moderation concepts)
On Tue, Apr 14, 2020 at 08:22:22AM +, Holger Levsen wrote: > On Mon, Apr 13, 2020 at 02:31:23PM -0700, Sean Whitton wrote: > > > The trust system gives me no trust at all. It is very closely bound to > > > participation over the web interface, monitors the reading frequency and > > > time > > > spent on reading by users. > > [1] > > https://meta.discourse.org/t/how-does-post-tracking-work-in-discourse/115790 > > thanks for pointing this out, Sean. This makes even using discourse > inaccepable to me, sorry. I think the problem isn't tracking itself. I'd trust Debian blindly in that :-) For me, the problem is the kind of anti-pattern promoted by this. > I also wonder where we will store this private data of our users, how > we will protect it and how users can request their data to be deleted. AsI said -- I'd espect Debian to not even collect that data. But even considering use a tool whose makers subscribe to that way of thinking seems iffy to me. Cheers -- tomás signature.asc Description: Digital signature
tracking our readers? (Re: Testing Discourse for Debian - Moderation concepts)
On Mon, Apr 13, 2020 at 02:31:23PM -0700, Sean Whitton wrote: > > The trust system gives me no trust at all. It is very closely bound to > > participation over the web interface, monitors the reading frequency and > > time > > spent on reading by users. > [1] > https://meta.discourse.org/t/how-does-post-tracking-work-in-discourse/115790 thanks for pointing this out, Sean. This makes even using discourse inaccepable to me, sorry. I also wonder where we will store this private data of our users, how we will protect it and how users can request their data to be deleted. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Testing Discourse for Debian - Moderation concepts
On Mon, Apr 13, 2020 at 09:33:20PM +, Andy Smith wrote: [...] > Not to speak for Neil, but it's generally argued that private > entities cannot censor, because a nation/state can tell you that you > cannot express an opinion using your own resources. By contrast a > private entity like Debian can only tell you that you cannot express > that opinion using *Debian's* resources [...] This is just the ultra-liberal way to see things. He who owns the resources has absolute say on their use. There are other legal systems and points of view. Absolute is almost always wrong :) Cheers -- "all generalizations suck" tomás signature.asc Description: Digital signature
Re: Testing Discourse for Debian - Moderation concepts
On Mon, Apr 13, 2020 at 02:31:23PM -0700, Sean Whitton wrote: > Hello, > > On Mon 13 Apr 2020 at 10:33PM +02, Mathias Behrle wrote: > > > The trust system gives me no trust at all. It is very closely bound to > > participation over the web interface, monitors the reading frequency and > > time > > spent on reading by users. > > It seems this is indeed so.[1][2] I hope that an official Debian > Discourse instance would find a way to turn this off. > > [1] > https://meta.discourse.org/t/how-does-post-tracking-work-in-discourse/115790 > [2] https://meta.discourse.org/t/discourse-new-user-guide/96331 (item 4) Well, this is downright ugly. Didn't know that, thanks for bringing it up. Cheers -- tomás signature.asc Description: Digital signature
Re: Testing Discourse for Debian
On Lu, 13 apr 20, 15:23:28, Dan Purgert wrote: > On Apr 13, 2020, Russ Allbery wrote: > > The thing with the "newer" projects that I've seen (and maybe I'm just a > curmudgeon trapped in a young person's body) is that they come off to me > as the early dotcom "exactly like X, except on the internet!" stuff. > > > Now, in a lot of cases the real conversation happens on GitHub, which > > isn't exactly the same thing as a forum. But forums seem to play a large > > role in some of the more vibrant communities (Rust, for instance). > > Haven't really gone there - I have noticed a lot of forums in regards to > microcontrollers; but I tend to just leech off of them as I can't stand > the whole "5th post on basically the same subject on the first page" > garbage that (beginner) fora tend to cultivate. Forums probably qualify for "like e-mail, except on the web", as they don't bring enough advantages to make them significantly better than e-mail. Discourse does have some advantages over forums. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Testing Discourse for Debian
On Lu, 13 apr 20, 14:23:30, Sean Whitton wrote: > > (a) would more clearly benefit from having more structure. It is less > clear that (b) would benefit, and (b) benefits from the posting of diffs > and replying using inline comments. It seems like Salsa would be better suited for commenting on actual code, though splitting the discussion is obviously not be optimal. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Draft Delegation for the Community Team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/04/2020 22:40, Sam Hartman wrote:> I'm pleased to finally be able to propose a Community Team delegation > for discussion. During the last year it has become clear that we > can accomplish more at lower emotional cost when we have the > Community Team, Account Managers and DPL working together, > supporting each other. It's become clear that the Community Team > does need a project-level mission/mandate. It seems to me that this delegation text does not improve the situation of the Community Team compared to the current non-delegated team. I do not think it serves the actual needs of the project, nor that it will help address the problems that have caused burnout and high turnover rates. * All of the activities of the CT seem subordinated to the interest and willingness of other parties to work with them and listen to their advice. No provision is made for when this is not the case. * In particular, Debian events are not required to do anything. This can result in big events going ahead without any kind of support for on-site conduct issues, as it was almost the case for DebConf19 (when the CT noticed the omission just before DC started). * It mandates the team to coordinate responses, but my experience shows that other teams -such as DAM or the DPL itself- do not always collaborate when discussions get heated and coordination is most needed. How is the team going to make that coordination happen? How is it going to prevent burning out people when they are left alone to face the angry mob? * There are mentions of community-wide harassment, which is of critical importance, but I see a lack of focus in the small problems that slowly but persistently erode the environment and result in Debian constantly losing volunteers. Is this not a need of the project? * At a first glance the people chosen do not seem to reflect the diversity of our project, which is of tremendous importance when dealing with cultural conflicts. The DPL has stressed repeatedly the need to find "the right people for the job", but I am still curious about the criteria. The less-than-transparent way personnel changes have been handled lately, combined with this apparent lack of diversity in the team that has been finally blessed by the DPL is not a great look, IMHO. In conclusion, I do not think this delegation is going to be effective in helping the CT become a sustainable and useful vehicle to better our community. It seems to lack the experience of the tremendous difficulties the CT has experienced in the past, which is not surprising as most of the members have only been very recently appointed and the experiences of past members and project leaders has been systematically erased. If anything, I see it as a limit to what the CT could have ever achieved; in a community that still struggles with finding compassion and kindness, while entitlement and privilege are still the norm, and figures of power cuddle with with some of the most reactionary voices in our community, this seems a step in the wrong direction. Much e-ink has been used to gather wide consensus on many technical details, whereas discussions around community building and policing are sorely lacking openness and transparency. There were many mentions of finding what the project needs to shape delegations, but I fail to see what are the needs identified that resulted in this proposal. Executing this delegation at the very end of a DPL term, during a pandemic where very few people seem to have any energy left for these discussions, and while a few dodgy things remain unexplained to the community is "most emphatically /NOT/ a way to build trust within the project¹". Tina. [¹] To quote a Delegate who compared another proposal with sneaky power grabs and emotional blackmail. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE2qbv8cYn6hwmsaaSqiMPxF+MJ7EFAl6VVJMACgkQqiMPxF+M J7HI0w/8Cl05LK2TnO5SBpK2uoIrwRTR/q6GyYJBV7nl5yjbsfYyczekgQ/rVYKq jS1Bz6Koi2yX5WFUV40gtvJ2x8uh/uySDCEjikfRGQLwwDrSC5Sjp3pai/jY0xj4 lSb0FIicHjS7CVAZ3D1B3Aegk9OWKLC567YVsEC6l8A5IzvqgfjeP/Dm1mg08BND guGTdlpHzhXLg/KtPFLx5c4kFfNsn2SHfDO8DzZjA2xBe333d5wpnIG84XEfAmvB IUVzlt+NLGtKTGPeIP2iKfyJnli2olExaQJFbPbGeloEu5kVQJM6qKYsAdpLMwLb 9Np+i9SL0ogLe1Dja1OC+cesZy0zpHT33dpzg2sHTKpzKEXf8YiX3+kBIMt5ATyT po45aKzQvR7F1Gbg1LFWyc2A5qDoN3q1Ogz8w4hgkVPW8vl52pvMCI4OedeY+/YF 2YXcOcLZxRJC51N6++meaU10oZ0x7FJNf8Hn+Voi1bs7BbAEz4Hr5cci0PePBXmP 1DoJ0GdMySPNJFQcbOffvareoiqqeceQhTgXhtH1sQyouXX43VsOEK8mAfz9+moD BPR02rHIRXXU84SpDwLEqzNAoVHTmu07jzIFDc2R6602Zh4pRbhcF3KcNhyRG64f RUbcBpuCbxONJtK8rA3FOwoIXfAgo48N9tGAs74c9mNejndryCo= =pPXn -END PGP SIGNATURE-
