Bid for UserMute feature

[grekko]

👋🏽 Hey everyone,

I'd like to bid on implementing the UserMute Feature. I tried to be as succinct as possible while not leaving out any relevant information.

If you are missing any information please do not hesitate to ask.

---

I noticed that the PR preview of the README.md I've included does not render the images I've added and am referencing from within the README.md. I hope that still works for you.

[grekko]

Hi @gravitystorm and @tomhughes,

I am pinging you since I figured you are the core contributors/maintainers of https://github.com/openstreetmap/openstreetmap-website and I am planning to implement the UserMute-feature.

I'd be grateful to get your feedback, comments or questions regarding the intended changes I am outlining here.

[tomhughes]

Pretty sure I have provided extensive thoughts on it before but no idea where offhand.

[grekko]

I've taken notice of this issue https://github.com/openstreetmap/openstreetmap-website/issues/3129 and this discourse thread https://community.openstreetmap.org/t/rfc-on-engineering-working-group-project/1542

I have token those into account when I was writing this up.

[tomhughes]

Yes those were the two that I just found.

I believe there is a fundamental disconnect between I how I see this working and how EWG see this working though.

Specifically I think that blocking a user should stop them being able to message you while EWG seem to think that they should still be able to message you but the messages should be hidden. Possibly they also think previously sent messages should also be hidden but I'm not sure about that.

Overall it's not something I'm hugely keen on because it promotes balkanisation where people don't talk to each other and we have quite a lot of that already.

[grekko]

I believe there is a fundamental disconnect between

Understood. For me as a 3rd party here with no experience inside the OSM community its hard to have a strong opinion.

I will have to rely on someone making the call here what behaviour is more useful to most of the affected users for which this feature is meant to be built.

[drolbr]

Thank you for the PR. The Engineering Working Group (EWG) will look into this in the coming days and circulate whether the description meets the people's needs.

Some background to resolve the confusion: the EWG has been tasked to help the openstreetmap-website maintainers (including TomH) to resolve the backlog. The merging of the actual code is finally at the maintainers' choice, so Tom's opinion matters for the details. The EWG has made an educated guess based on the issue what in detail is intended. The assumption is based on how members usually use messaging services.

This feature has been chosen as the first to start with because it has relatively little cross-dependencies with core parts of OpenStreetMap, but is UX related. So we can see whether and how people react to explain their unspoken habits and expectations and settle on a consensus when prompted with a proposed implementation. If the final results meets the agreed-on specification but is not joined into openstreetmap-website ultimately for reasons outside your control then the EWG still considers the work as accomplished.

[grekko]

Hey @drolbr thanks for the reply.

The merging of the actual code is finally at the maintainers' choice, so Tom's opinion matters for the details.

Sounds good. I am grateful for Tom and/or Andy supporting me to steer into the right direction.

This feature has been chosen as the first to start with because it has relatively little cross-dependencies with core parts of OpenStreetMap, but is UX related. […] If the final results meets the agreed-on specification […] still considers the work as accomplished.

Of course I am eager to start working, but my main interest is to provide value to the project. So from my point I am open to spend more time into figuring out what actually should be build and am flexible to adjust to new circumstances or requirements.

[grekko]

@tomhughes I hope I am not complicating things here, but I'd like to address your concern of the balkanisation of the community.

Overall it's not something I'm hugely keen on because it promotes balkanisation where people don't talk to each other and we have quite a lot of that already.

I understand you worry that users could start to progressively mute other users. Then given that the mute-feature logic would be extended to also filter other communication channels – not just the private messages – users could be creating their own communication bubbles. Did I understand this right?

How about we design a UserMute with a inherent expiration date of a sensible short duration, e.g. 48 hours, this way the UserMute is really just a tool for users to throttle incoming messages from users until the conflict/situation is resolved the usual way – by a third party e.g. Admins/Moderators who have to mediate and eventually make a call how to handle the situation.

[grekko]

@tomhughes adressing your point about blocking vs. muting

Specifically I think that blocking a user should stop them being able to message you while EWG seem to think that they should still be able to message you but the messages should be hidden.

When you write

should stop them being able to message

Do you mean that the blocked person should not have access anymore to the "Send private message"-Feature for the duration of the block?

If so, I understand that blocking a user would be a transparent action which could lead to further irritations since the blocked person would be made aware about the fact that they are blocked and who blocked them.

Muting on the other hand would be non-transparent. It just shields the person using the mute-feature from unwanted messages and/or notifications about it without making it transparent to the muted person.

Is that a correct assesment or if not, how do you describe the differences between blocking and muting?

[grekko]

@gravitystorm I was asked to ping you again on this matter, since I need your support to start working on this.

[gravitystorm]

I've reviewed this proposal (by cloning the repo so that I can preview the images inline - they are very useful).

I would be happy to see the project implemented as described. I'm keen to see the muting feature cover the following scenario:

• Two users have some history, perhaps outside of OSM. User A (the 'victim') simply does not want to hear what User B has to say, regardless of content. They want to mute the user, but they don't want to give User B the satisfaction of knowing that they have caused more annoyance. Therefore the muting should be silent, and fully under User A's control (i.e. no automatic time limits).
• User C writes a lot of messages of encouragement and critique to new mappers in their area. User D initially feels overwhelmed and mutes User C, but changes their mind later and wants to see the messages that were sent in the meantime. Therefore the messages should be reviewable and not lost into the void.

I also think it's important that users are given full agency here, to block people, change their mind, review blocked messages etc without the other user being aware of what's going on, and without anything having to be judged by any moderators. It should be a personal choice whether to mute users and whether to receive these messages.

I don't agree with @tomhughes that users should be blocked from sending messages, based on both the requirement (in my view) for muting not to be publicised to the muted person, and also the requirement (in my view) that muted messages can be retained and reviewed by the user later.

[tomhughes]

I did have various conversations on IRC about this after this ticket was first opened and I was at least partially persuaded on the question of muting versus blocking - there had also been some confusion around a meeting and discussions that took place in advance of this ticket being opened that I had been unaware of.

My immediate concern about blocking was primarily simply that it felt rude to me to allow people to go on writing messages that would never be read. I realise that people can always just not read the message but somehow it feels different if that decision has been made a priori by the recipient. That said moving the messages to a muted tab, which I've only just discovered is the plan right now, seems like it goes a long way to addressing that worry.

I do also seem to have a more cynical view than many people about much this will be used and to what purpose - while others tell me it's about people being abusive (which I'd rather was reported to be dealt with rather than being brushed under the carpet) it seems to me likely that people engaged in edit wars etc will use it to ignore each other. Then again maybe that will help cool the situation down...

One big advantage of muting over blocking is that it could in theory be extended beyond private messages, though that quickly gets problematic given things like changeset and diary comments aren't threaded so you'd potentially be blocking random bits in the middle of a conversation.

There's no need to clone to view with images inline by the way - you can see them in github by looking at the file in the source branch I just hadn't done so before because I hadn't realised this was a PR that had files.

If we're going to have per-message mute flags then we should probably have a way to mute or unmute a message as well and probably when a user is muted or unmuted there should also be an option to do that to all existing messages for the user.

Possibly you should also be able to mute (or unmute) a user directly from the message view page rather than having to go to the user page?

[AndrewHain]

@grekko The Engineering Working Group would like to review your proposal and invite you to our forthcoming meeting.

[grekko]

@grekko The Engineering Working Group would like to review your proposal and invite you to our forthcoming meeting.

Thanks for the invite. I am happy to accept and am looking forward to meet you then.