we the Engineering Working Group (EWG) now would like to start asking for bids on projects. This one is our first.
We are open for comments on this one until our next meeting on 2022-06-06. Please send any feedback via this channel or as a pull request. We then would like to use the feedback to improve the project description. The next step then is to put out the improved project description as call for bids.
It is on purpose a rather small one: We need to probe whether there is interest at all and whether the process of public consultation, then call for bids, then selecting an offer based on the project funding framework
and monitoring its implementation is doable.
I’d love to know how they’re going to decide if a pull request is “mergeable” or not… Do EWG evaluate if it’s mergeable independent of any decision by the web site maintainers on whether to actually merge it?
I mean anything that is actually created by making changes based on a branch from the current code is technically mergeable in a literal sense.
So be that definition you could write code that never got merged but still claim payment on the grounds that it was theoretically mergable…
Thank you for the remark. I’d define “mergeable” as:
technically mergeable including passing the respective testing policy plus
the maintainers of the project accept the PR
The EWG might only decide to pay if the PR is technically mergeable, but the maintainers decline to merge for reasons not based on the produced code. Obviously, if the PR has side effects outside the intended feature then this might be a perfectly valid reason to reject the PR and declare the project failed. Whilst if the maintainers simply do not reply on time (I have no concerns regarding openstreetmap-website of this) then it only would be fair to pay the supplier and care ourselves to get the PR ultimately merged or abandoned.
Simply said: we trust the maintainers to do the right thing. Only if this goes massively wrong then the EWG wants decide on its own.
What testing and evaluation is planned beyond code-level testing? I’m thinking here of the many OSM communities who collaborate to create the map locally and occasionally have to deal with people who don’t want to accept what most other people think is a consensus. “harrassment” is something of an irregular verb - I give helpful advice, you are harrassed, they complain to the OSMF board.
Is it planned to stand up and widely advertise a test environment with the relevant functionality in it so that everyone (who may not be following the website code on Github) can have a look and think about the impact locally?
A few random points, where additional clarification would be needed:
As already mentioned on the Github issue, don’t call this feature “Block other users”, we already have “User blocks”, and it has an entirely different meaning.
Showing the user id on the UI is probably a poor UX choice, and we don’t do that anywhere else, except for the API XML/JSON response. I can imagine where this is coming from (user might have renamed their display name). It’s probably better to simply provide a link to the user profile instead.
What should happen if the “offending” user is being deleted/set to inactive?
What should happen to email notifications, which are sent out alongside an OSM message? Are they also silenced? What will happen if I unblock a user in that case?
Are such blocks time limited (like in the case of Discourse, where you’re reading the original version of this text)?
Where exactly on the UI should the new feature be included? A low fidelity wireframe would be really good even in the proposal.
Are blocked user lists private to a user, or can moderators / administrators inspect those lists using some UI, or run statistics on them to identify “problematic” users?
What would be the expected behavior when a blocked user sends a message? Would they receive an error message, or would the message be silently discarded? (it’s a policy choice really, but currently undefined in the proposal).
Which type of user can be blocked?
When I as user A send a message to user B, user B would receive an email notification, and can directly reply back to me via this email (it has a message specific From: email address, like m-00000-000@messages.openstreetmap.org ). Once I block user B, any email notification sent back to me using this email address also needs to be blocked.
From past experience with Add user interface for moderators to hide note comments · Issue #1934 · openstreetmap/openstreetmap-website · GitHub, I can only stress the importance to discuss those topics in as much detail as possible upfront. As it stands, the level of detail currently presented in the proposal is not sufficient to be handed over to some development resource. In particular, I wouldn’t leave any “business logic” decisions open to a third party resource, and rather define any sort of business logic in the proposal right away.
I don’t really think you should expect them to nail down every minor detail at this point - those sort of things are what we will discuss as and when a PR is opened and if EWG tried to nail them down at this point there’s a risk they’d get things wrong and they would have to be changed later anyway.
Many of your questions have (to me, as a maintainer of the code in question) pretty obvious answers anyway - obviously it would be ridiculous if email notifications were still sent as it would defeat the entire point of the feature.
One thing that I find curious is that everybody seems to be assuming that you can still send a message to a user that has blocked you and they just don’t see it - my assumption would have been that a blocked user couldn’t actually send you a message in the first place. That is the sort of fundamental question that we should be worrying about at this point rather than minor details.
Totally agree, my motivation is of course slightly different here. Imagine you would need to come up with a cost estimate for this task, but don’t know all the details of the application or what’s in scope for the task. A somewhat comprehensive list of acceptance criteria would be helpful to avoid bad surprises later on. By the time a PR gets opened, we’re already way past the bidding stage, so that would be a bit late to discuss details which may have some cost impact.
Just for clarification, we’re not talking about User blocks | OpenStreetMap here, but a new to be developed personal list of users you don’t want to receive any more personal messages from. Essentially this means such an API call would probably return different results, depending on who’s calling the endpoint.
Could you elaborate a bit more, maybe? I’m not sure I’m getting your use case here. Is this some kind of spamhaus idea where you publish a list of bad OSM user ids, and some job is updating your own block list from time to time without further manual action needed?
In that case, it would probably make more sense to block such a user altogether, right?
I’ll put the request for user acceptance tests on the list what the EWG should consider in general.
Here, I understand the express purpose of the feature is that a user can reduce the size of his/her inbox. And unblocking a user will even bring back the non-deleted messages from that user. As such the feature has no interaction between users, and is a pure enhancement without disrupting existing workflows. Only in that way of understanding this is a small project.
So the whole user acceptance dimension can be skipped here, and the only acceptance that, again here, is mission-critial is of the maintainers of openstreetmap-website.
Note for future call for bids: We should ask the maintainers to review the bids.
I’m sure that no ealier than when the maintainers see the bids of the applicants we know whether everybody is on the same page. It is almost always possible to misunderstand the maintainers’ intentions. There should be a balance between too long and verbose project specifications and being so vague that nobody understands what the maintainers really want.
That is really not the purpose of the feature as I understand and I would absolutely not take a PR which added it for that reason because it’s the wrong solution if that is the goal.
My understanding was that this was to allow users to block abusive correspondents.
I see no reason to support sharing lists of blocked users though - that runs the risk of promoting a lynch mob pile on type of behaviour and seems entirely unnecessary to me. It’s certainly not needed for a minimum viable product even if it is desirable.
That was also my understanding, and also what @Stereo has written on the Github issue: “If I block someone, it should stop them from sending me messages”. It doesn’t say I want to filter certain users in my inbox view (and still receive those unwelcomed messages via email).
yes, but in some cases users were active for hours/days after report. Though maybe they kept adding invisible spaces to name or done something else that confused people, and they were actually blocked faster?
I’m sorry there had been room for misunderstandings. Obviously, the email notifications should stop as well. Note that I would call the folder where I receive standard email also my “inbox”.
As I understand to feature, the website assists the user A to not be bothered by user B’s attempts of direct communication. Renaming the feature to “mute a user” probably helps to get that clear.
Not included in this feature is any social dimension. We do not want any facility to export or share lists of muted users. And there is no reason to notify the muted user, because there also would be no notification of the muted user if the muting user would just have deleted the unread message.
The best blocking experience I’ve ever seen is on iNaturalist (Top right, click your avatar, account settings > relationships). I like how it distinguishes blocking and muting, how it explains everything well, how reasonable it is, how you can mute as many people as you want, but by default only block three, and how it has an easy path forward to report harassing or stalking.
