Imagico.de

blog

OSM related group communication channels and platforms – revisited

| 13 Comments

The OpenStreetMap foundation has rolled out their new web based communication platform – which has long been anticipated and which i have mentioned in passing in my yearly OSMF review already.

I want to take this opportunity to update my previous review of OSM related group communication channels and platforms and add a few subjective impressions and comments afterwards.

After having essentially stopped using OSMF communication infrastructure actively in response to the OSMF board establishing a highly questionable behavior control regime and indicating the intention to extent this to all OSMF controlled communication channels, i view this pretty much from an outside perspective now.

But as said – lets start with the basics. Here is the extended table of the different communication platforms and their evaluation according to the different criteria i introduced in the first part.

OSM related group communication channels

I differentiated the open platforms and communication protocols category further into:

  • Free open source software: This documents the basic question if the software used is formally licensed under an open license.
  • Open protocols: The question here is if the platform can be interfaced with from the outside (both technically and legally) to allow exchange of content with other platforms or alternative interfaces.

I think it is important to separate these two – the latter is also possible without the platform itself being open source and a communication platform based on open source software does not automatically provide open protocols that can be used from the outside to access or to enter communication content (which is what seems to be the situation with the new OSMF platform – see below).

Here the updated footnotes for the table:

  1. help.openstreetmap.org has limited support for structured communication.
  2. The OSM wiki in principle allows structured communication and on talk pages it is established practice to thread messages. But you have to do this fully by hand and it only works if everyone does so diligently. No builtin support for that.
  3. On Usenet server operators used to expire messages so there was practically no permanent public record in the system itself. However everyone running a Usenet server could maintain a record and in the late days of Usenet Google practically served as a reference record.
  4. The forum indicates when a post has been modified after initial posting but no record of the original message is retained. Also admins on the forum can (and do) remove messages from the record (with varying frequency, depending on the channel).
  5. The diaries themselves can be edited without the history being visible but the diary comments cannot.
  6. On the wiki the edit history is openly accessible so it serves as an immutable record (though it can be difficult to use as such practically).
  7. Github has a fairly clever system of allowing edits of communication but still allowing users to transparently see if there have been changes and what has been changed. Github however also allows completely removing messages from the public record in some cases (but it is indicated at least that a message has been removed i think).
  8. While there is no alternative interface to posting changeset comments for reading there is the popular tool by Pascal Neis.
  9. Openness in participation in principle applies to most OSM related mailing lists and forums. There are a few exceptions – specifically osmf-talk is only open for posting to OSMF members. There are thematic and regional lists and forums with culture specific rulesets you need to accept for active participation which are usually developed through consensus of those active on the individual channel (like diversity-talk, regional forums). Beyond that the OSMF has for all communication channels and platforms they operate indicated the intention to impose a behavior control system that is designed to allow banning participants if they misbehave in the eyes of the moderators. To what extent that practically limits the de facto openness is not clear so far.
  10. See 9 – plus Discourse seems to implement an automatically managed hierarchy of users based on their formal activity history on the platform. In addition there seems to be a not publicly documented number of people selected from the top so to speak who have special privileges in editing/removing communication content of others. So the system is essentially open only on the base level and has an elaborate hierarchy built on top of that. If people are also manually promoted/demoted within the – on the lower ranks – by default automatically managed hierarchy is not clear to me yet.
  11. Discourse formally seems to record communication structure in the sense that it records which message a message is in reply to if it is explicitly made in reply to one. This is however not consistently displayed. I have seen messages being shown both as a reply to another message as well as being shown a second time as a flat comment to a topic. In general the whole interface seems to strongly discourage replying to the messages of someone else in the sense of structured communication and to nudge people to preferably add comments in a linear fashion to a topic.
  12. Discourse seems mostly like the forum in this regard (see 4. above) but in addition seems to allow you to see the edit history of messages. There seem to be also automated edits of messages made by the software – which are displayed just like human edits. It is unclear to me so far if message removals by moderators are transparently visible or not (i.e. if there is an indication that here a message by X has been removed). Update: It seems that moderator action is not generally publicly visible as such.
  13. From what i have seen Discourse has an API but that is not openly accessible – not even for read-only purposes – but requires an API key from the platform operators. The OSMF has so far not indicated if they are willing to provide access to that to anyone. I have not seen any external clients that interface with discourse in some form based on that API or otherwise. In particular there does not seem to be any workable mechanism for bulk access to the communication content. There are secondary channels (RSS feeds and the so called mailing list mode) that allow limited access to some of the communication content but they seem to be there mostly pro forma (to be able to advertise those as features) and are practically essentially unusable (Update: more details in comment below).
  14. There seem to be some very limited filtering options (like blocking individual users) for logged in users w.r.t. notifications. The message reading interface however does not seem to have any way for users to filter things (although the platform itself performs filtering on its own – deciding based on unclear criteria which messages are shown and which are hidden by default).

Another remarkable data point by the way: The starting page of commmunity.openstreetmap.org loads an impressive 5.4 MB of content to then display what amounts to less than a hundred words. For comparison: The OpenStreetMap forum starting page (which is much more information rich of course) is less than 100 kB.

Personal impressions

When i am in need to choose a software or platform for a certain purpose my primary consideration is usually: Does it allow me to do the things i want to in the way i want to do them without the need for me to invest time and resources in things that are not of interest for me. To give an example from the field of group communication: In case of image content as part of communication and graphical formatting of text: I would want the communication tool to show me the fact that my communication partner has communicated such content but i don’t want it to show me such stuff without me explicitly choosing to see it. In other words: I want to be able to make granulated decisions on how much attention i invest in a specific communication.

The central paradigm of Discourse seems to be pretty much the opposite of that: Active management of the user’s attention. Like:

  • Suggested Topics – who is suggesting that to me and why? I have not asked for suggestions of any kind.
  • Views, likes etc. – apparently someone thinks it is of tremendous importance for me to know how many other people have read or indicate to have liked what i am reading so they rub that into my face prominently and this way distract from the actual communication content i am reading. Too bad that i don’t care about this kind of data.
  • It seems it is also of high importance that i always associate the identity of my communication partner with some picture of their choosing. Tough luck if memorizing mini-pictures is not really your prime talent – because you then have to deal with the between one and three verbal identifiers which are displayed in various tones of gray and weight in a way that is barely discernible from the communication content.
  • Hello! Looks like you’re enjoying the discussion, but you haven’t signed up for an account yet. Seriously? I am just waiting for clippy coming around the corner now…

I could go on with a long list of similar things i find appalling when trying out the new platform but i will cut it short. Discourse is evidently not for me. My impression is that the target user group of that platform is people that have grown up in the attention economy, using twitter, facebook and other social media and feel comfortable with those.

Conclusions

And i think that is fine. As indicated in the past (and others see this similarly) i am convinced that a diverse project like OpenStreetMap needs diverse communication platforms. People who are used to twitter and facebook and like the communication style there should have the opportunity to communicate in a similar style about OpenStreetMap and preferably using open source tools and without the need for people to participate in that communication to sign up with some big corporation and agreeing on their data being sold for profits.

What i see critically – and i have said that in the past as well – is, that there are strong voices in the OSMF that do not just want to offer this new communication platform as an option for those who like this style of platform but who want to unify and to culturally homogenize all OpenStreetMap related communication under this. Kind of the wild dream of all community management. It is very likely that this would fail of course but there is a significant risk that the failure would not be visible from the inside perspective and that at some point in the future people on community.openstreetmap.org might predominantly believe that they are the community (or at least that they are representative for the whole OSM community in all their diversity).

Discourse belongs into the category that i have described in the previous post on group communication channels as stuff developed around some fancy web interface meant to serve the fashion of the day in UI design. It is very likely that this will – like countless other similar platforms in the past – run out of fashion relatively soon again (in like 5-10 years) and will, as a software, likely become unmaintained soon after that. In other words: It could well be that the OSMF will in 10-15 years, possibly sooner, be in more or less exactly the same situation it is right now with the forum and help.openstreetmap.org running old and unmaintained software – just with the software then being discourse. The irony could well be that mailing lists still exist then…

We have a saying in German: Die Zeiten sind hart, aber modern.

13 Comments

  1. Only a small remark on the data transfer: The initial page load for Discourse is big but afterwards requests are JSON API calls. So once the JavaScript stuff is cached once, any later visits just pull the data and that is very comparable to a standard forum’s request sizes.

    • My discussion of the data volume was about bandwidth efficiency (data volume needed per volume of functionally meaningful content for the user). I don’t think the difference between forum.openstreetmap.org and community.openstreetmap.org in that regard is purely due to a large volume of code being loaded initially. When – after calling the main site – i move to https://community.openstreetmap.org/c/site-feedback/issues/36 that requires an additional 100k. When i move to https://forum.openstreetmap.org/viewforum.php?id=14 on the legacy forum (which is again more information rich compared to discourse) that loads 30k. When i move to an individual topic (like https://community.openstreetmap.org/t/downvoting-for-support-topics/743/17) that is 80k for the initial page, 290k once i scrolled to the bottom, when i scroll up and down again after a few minutes that raises to 700k. A comparable volume topic on the forum (https://forum.openstreetmap.org/viewtopic.php?id=75249) is 44k. So: Yes, the most excessive bandwidth inefficiency is for the initial page load, but you still have massive bandwidth consumption relative to the volume of actual communication content you consume during further use. When you are on a metered connection browsing that site can quickly become rather costly (or time consuming when you are on a low bandwidth connection).

  2. You could have addedd Mastodon, in particular en.osm.town, which is now backed by OSMF: https://www.openstreetmap.org/user/᚛ᚐᚋᚐᚅᚇᚐ᚜%20?%EF%B8%8F%E2%80%8D?/diary/397571.

    • To this and Albert Mudat:

      Evidently the choice of channels i looked at is somewhat subjective. I based the selection primarily on:

      • As written in the first part this analysis concerns group communication in the sense of symmetric communication between more than two participants on equal levels. That makes inclusion of microblogging platforms questionable (because of the inherent asymmetry of all communication there) – Though you can of course argue that with its strong hierarchical elements Discourse is equally questionable to include.
      • The significance in the OSM community in terms of how much OSM specific group communication happens on such channels. There is little hard data on this so there is evidently some subjectivity in that assessment. This also supersedes the first point to some extent – i included the diaries despite their clearly asymmetric nature because they are prominent on the OSM website and widely used and read in the OSM community.
      • The open accessibility of the platform at least for reading to allow me to study how it works without the need to sign up with some corporation. This is where Discord fell out.
      • The historic significance of the platform for digital group communication in general – this is why i included NNTP/Usenet.
  3. Discourse is highly customizable. Just about every single point you’ve mentioned in the “personal impression” section can be adjusted in some way or another, mostly even without any coding. meta.discourse.org has lots of detail in case you’re interested.

    Now, if you really want to help improve things, I’d recommend to post your suggestions on community.openstreetmap.org.

    By the way, have you tried the mailing list mode in Discourse already? This might be a good alternative for people who don’t like fancy UIs.

    • Thanks for the comments.

      To avoid misunderstandings on a fundamental level – i am discussing here the communication channels and platforms that are practically available to the OSM community. That means i am discussing the OSM wiki as it exists on wiki.openstreetmap.org and not mediawiki as a software. I am discussing the OSM forum and not FluxBB. I am discussing mailing lists and not mailman. I am sorry if by talking about Discourse i might have created a different impression. I maybe should have simply talked about the new forum. If what i observe are features and limitations of the software used or specific to the configuration of the software as it is available to the user is of no concern for me unless the normal user without special privileges is able to adjust that (like in case of mailing lists where the user is free to choose the email client and therefore has control over what filtering options are available to them).

      Now, if you really want to help improve things, I’d recommend to post your suggestions on community.openstreetmap.org

      I don’t think i have made any suggestions – and i did not intend to. If you or others active in the design of community.openstreetmap.org want to derive ideas how to improve it from what i write you are welcome to do so. But you should not mistake this commentary as free consulting work.

      By the way, have you tried the mailing list mode in Discourse already?

      I have. As written in the text it is essentially unusable because the mails sent out are not standard compliant – references are complete bogus and they are multipart/alternative mails with some weird mixture between bb-code and markdown being incorrectly classified as text/plain (and even if i ignore that and simply try to interpret it as markdown it is not working – because of nonsense like ![Capture d’écran du 2022-04-02 22-25-28|453x500](upload://iI5QZXGWBPpmPX6RTVXKBhHMPs1.png)).

      • I think you raise a valid point that from a user perspective, it doesn’t really matter if limitations or certain behaviors are inherit features of a platform (e.g. “Discourse”, or “fluxBB”)), or simply caused by some (default) configuration that is in place on community.osm.org right now.

        On the other hand, it’s important to highlight that the current set of features and settings isn’t set in stone yet, and there’s still ample opportunity to shape the platform in ways that make it more user friendly. You’re probably not the only one who is annoyed by the “attention economy” and outright silly suggestions (see “clippy” above).

        I guess, you would have to discuss those topics with other users, and come up with some kind of compromise that will apply to everyone later on (as opposed to run your own email client and do whatever you like).

        > I don’t think i have made any suggestions – and i did not intend to.

        Well, at least you’ve collected a somewhat lengthy (yet still incomplete) list of things you found appalling when exploring the new forum. Raising those points in a structured way – as you did – is really helpful to validate and cross check how different users perceive certain features. It’s always much more helpful than a simple “I hate the new platform” without providing any reasons as to why.

        > […] i ignore that and simply try to interpret it as markdown it is not working – because of nonsense like

        That could very well be some configuration issue. Mailing list / email mode is still a bit experimental right now, and there may be still some rough edges.

        • To try a bit to take up the cudgels for those who just say I hate the new platform – it is – on average – not realistic to expect from someone invested in communication on a platform like the OSM forum (or in other words: someone from the highly culturally diverse group of people who have contributed substantially to the 700k+ non-English posts (of a total 832k) of the forum), when being told that your platform of choice is going to be turned off sooner or later and that you are suggested to move to a new platform that has been set up by a group of people with evidently fairly specific communication preferences to go there and explain in a friendly fashion what exactly they dislike about that platform. Cultural diversity issues aside – it is a bit like having a pub in some village and the pub operator tells his visitors one day that he has opened a new pub on the other side of the village with more space, more comfortable chairs and a broader selection of drinks and he asks everyone to move over there over the next weeks because he is going to close the old pub. And if anyone dislikes anything about the new pub they are welcome to fill out the customer satisfaction reports lying around there to detail what exactly they would like to change and how.

          As said there will evidently be people who like the new platform and some might also dislike it for the moment but will adjust to it and over time feel at home there. And therefore it is good that such a platform is offered. But it is at best naive to believe that you can just transplant the communities that have formed over the years on the forum and elsewhere to the new platform, add some community management, sprinkle over it some technical gimmicks and a code of conduct and have a happy place where everyone feels welcome and at home.

          • This sudden change feels *a lot* like what happened in the Erlang community recently. At first[0] no one seemed to notice it (me included) but when the people realized the “takeover” wind started to ruffle the leaves[1].

            In Erlang’s case someone decided to move just like that, while simultaneously deprecating the ML. Whose decision it was to make the move I don’t think anyone in the community knows. But from the replies made by some Discourse staff guy trying to calm people down and to sell his fish, it sounded too much of corp BS.

            Worse of all, whoever made the decision didn’t share their intent with the community beforehand, they just went with it and announced the move after-the-fact.

            My own opinion about the move (both Erlang’s and OSM’s): it’s sad how the “new hip thing” comes along to “replace” the old even though /the old is the superior in many ways!/ No one can’t seriously believe email isn’t without its faults, but starting to use some more closed platform is not the right way to go. To me, Discourse is just another place where information goes to die.

            Having said that, I share Chris’ thoughts in that I’m not trying to stop anyone from using such a thing, even though I personally dislike it — preventing people to communicate with each other is worse than given them bad communication means.

            [0]: https://erlang.org/pipermail/erlang-questions/2021-October/101583.html
            [1]: https://erlang.org/pipermail/erlang-questions/2021-December/101685.html

          • Thanks for the comment and for sharing an example from elsewhere.

            I however specifically like to point out that OSM is decidedly not a tech project. While we have many of the problems tech projects tend to have as well (partly because a lot of influential people in OSM treat the project like a tech project) it is important that the solutions to these problems that are devised in the context of tech projects will not work in OSM – unless you try to turn OSM into a garden variety tech project.

            I did deliberately not go into the details on the motives to introduce and push new tools and platforms in this post but there are definitely political motives and search for power and control present. What amazes me in particular and what probably would deserve a deeper look from a sociological and psychological perspective is the level of negative motivation present, i.e. how significant the dislike and outright hate for traditional communication channels and their users is in the motivation of some people who promote the new channels.

            The intention to invest into a new, centrally managed communication platform has been communicated by the OSMF for quite some time now. The motive communicated was always to replace the help.openstreetmap.org and forum.openstreetmap.org platforms because they run unmaintained software. It was of course also always clear that this is just one of the motives behind this move and many active in the OSMF (both on the board and in some working groups) have for a long time indicated that they like to use use this technical necessity to implement political changes and to steer the OSM community into a direction they perceive to be desirable. The problem was not so much that there was no communication about these plans and the motives, it was more that in light of the strong interests in this change the warnings (both the ones articulated – like here as well as the warning signs indirectly visible if you look at how existing channels are practically used) were largely ignored or dismissed.

  4. Pingback: weeklyOSM 611 | weekly – semanario – hebdo – 週刊 – týdeník – Wochennotiz – 주간 – tygodnik

  5. Client-wise, there’s nothing one can do about the bandwidth wastage and social anti-features. However, I am working on a browser addon that will rid the site of most of the avatar overdose, gamification and nudging, so that you can view it without risk of eye cancer and brain damage.

Leave a Reply

Required fields are marked *.



By submitting your comment you agree to the privacy policy and agree to the information you provide (except for the email address) to be published on this blog.