Let's close this Discourse instance

Meta Discourse
7

Discourse is a fine platform, probably even a good platform once you are accustomed to it. I believe the Scala Community is has enough dedicated members to be able to support its own choice in tools and I do believe the discussions here need a place. For those reasons, I would anticipate this instance will do okay. I do especially agree that the Discourse instance is a good step up in replacing the mailing list with a more modern platform.

Thoughts were for the new users (and contributors) that, in my opinion, Scala needs. Unfortunately, I cannot think of a good way to measure the impacts of GitHub vs Discourse this and have I only have my personal experience and observations, both of which are unfortunately subjective and easily in error.

I have read numerous accounts of increased participation after moving to GitHub (which is why I was looking into moving the Scala JIRA to GH Issues), but they have all been the experience of one project and I don’t know of any study with a large enough sample size to know anything conclusive. GitHub is not a perfect platform, but it is where users are at and has proven itself flexible enough to be used successfully for a diversity of projects and scales. I see moving to GitHub as moving to where the users are rather than asking them to come to you.

Just to expand a little:

  • GitHub is a barrier only once. Chances are good they already crossed this barrier before finding Scala. I am comfortable discounting this barrier as one that Scala needs to concern itself with.
  • With the Discourse instance, the user needs to sign up. Even users with something to say, or who might just click “like” somewhere can be stopped by this. A mental measure of engagement occurs that decides if whatever action they would have taken is worth clicking sign in and creating an account. This loses potential contributors. Even small participation can work to later pull in a user to a more active role. They can sign in with GitHub, which helps, but they learn that only after trying to sign in.
  • There is a parallel line of reasoning with the above with Discourse as a [potentially] new/unknown platform which can intimidate or otherwise deter a [potential] user.
  • Scala is significant, but it is still not a broader norm. Also using tools outside the norm may not hurt general approachability, but does not help.
  • The Discourse instance is not as discoverable as a GitHub Project. This can probably be largely remedied with a bigger marketing push for the Discourse instance. However, the Discourse instance is not something a user expects to find or will necessarily go looking for. It is only after seeing a link or refernce that its existence is known. Conversely, if a project is hosted on or links to GitHub, GitHub Issues is assumed to exist until shown otherwise. Potential users can’t know what they don’t know.
  • This is not specific to platform choice, but at least to some the “Contributors” name suggests an exclusivity that, while not intentioned, may give potential participants pause. Tying discussions to their projects as typical on GitHub helps to level this distinction.

Concerning fragmentation:

  • I have discovered and participated in a lot of projects by following cross-repository references in GitHub. This is a discoverability feature is lost when part of the picture is on Discourse.
  • Discourse does this better than mailing lists and categories do help, but trying to put all discussions in one place raises the signal-to-noise ratio for users and can lead to lower engagement. I find the trend towards modularization and GitHub help this. The open source projects I feel I have contributed the most to are those that I ended up “watching” on GitHub because that keeps me informed and engaged. GitHub issues that affect or interest me are then pushed to my e-mail. Related issues are likely to be cross-referenced so I learn about those as well and can choose to subscribe to them if relevant. This becomes sort of engagement becomes intractable beyond a certain scale, thus watching the “river” of the entire Scala Contributor Community is not something I’d be inclined to do and why I have never stayed successfully subscribed to mailing lists. Instead I need to make an effort go to Discourse if I want to see what is happening.
  • I agree with @jducoeur on badges/rewards provided by Discourse. Were I to accept that Social Reward is a relevant factor, then Discourse also fragments my Social Presence and weakens my Social Status on GitHub because my participation here will not appear in any metrics there.

I am not convinced there are conversations that could start here which do not, and could not, have a clear place on GitHub. If there are, Discourse may be the right place for those. My opinion is just that GitHub is the more expected place for “business” such as in depth discussion a project such as is happening with the Scala Platform and that following expected behaviors encourages discovery and participation.

I keep being concerned about abuse on the GitHub platform, but, for its size, surprisingly and happily, I have yet to see anything requiring intense moderation or suggesting that moderation on the platform is deficient. Issues do need to be managed (moderated), but I have seen so many cases of GitHub working, and of working well, that I struggle to see it as unworkable for Scala.

None of my concerns are such that they are going to break or cause anything to fail, but together they seem enough to me that they could impact who participates.

8

I am not sure I follow this. Issues are sorted numerically by default; however there are other sort options, including most recently updated, most commented, and most up-voted. It is also easy to narrow by tags, milestones, etc.

9

It appears this is possible. We just have to do some configuration on our installation of Discourse to allow replying via email, it seems. Will figure it out when back in the office…

10

And this is a good thing. You completely overestimate the value a newcomer can provide. In my experience the contributions of newcomers are in 99% of the cases a nuisance to burden. Making it easier for newcomers means to make it harder for the people who do the actual work. And they are almost always more important.

Sure, it is a great thing for people to claim that they received more contributions after moving to Github but that is rarely the case because the community is at Github, it is because the systems they used previously were outdated and hard to use. Furthermore, most of the work of newcomers is trivial: fixing spelling mistakes in documentation, resolving formatting errors and the likes. These changes are nice to have but not essential for the overall quality and the success of the project.

In the end, someone who wants to contribute will contribute - regardless of the platform.

11

I think there’s some misunderstanding, perhaps @vossad01 assumes Discourse is replacing everything rather than just being for “contributors” whatever that means. Still I find your reply disturbing; hopefully you didn’t mean it the way it sounds.

You completely overestimate the value a newcomer can provide. In my experience the contributions of newcomers are in 99% of the cases a nuisance to burden.

It sounds like you’re going on record that this forum is purposely not welcoming to newcomers. Without even addressing your logic, that’s not a healthy reputation to have.

As for the logic, (1) the fact that you consider it a nuisance may be due to your values. If the sole goal is “getting things done,” well what is the value in things being done, if not to help people (hopefully not just yourself). (2) It’s incomplete math. If 99% of newcomer posts are a waste of time and effort worth for argument’s sake -1 units, and 0.01% of the time a newcomer post brings a new insight or idea or other contribution worth +1,000,000 units, then we should want to have tens of thousands of newcomer posts!

most of the work of newcomers is trivial: fixing spelling mistakes in documentation, resolving formatting errors and the likes. These changes are nice to have but not essential for the overall quality and the success of the project.

Not sure what the definition of “most” is here, but I strongly disagree with the assessment. These changes are essential to the overall quality and success, not only because keeping things up to date is something that needs to be crowdsourced, but also for the health of the community’s morale.

Also I’m not sure why that was in the second paragraph, not the first.

I suspect what you mean to say is, “it’s not worth being picky about the fact that there’s an extra OAuth screen, because the chances of that filtering someone out, and that someone being a potential valuable contribution, seem small compared to the value that Discourse provides.” It just didn’t quite sound that way.

In the end, someone who wants to contribute will contribute - regardless of the platform.

Evidence? My firsthand experience (with my own choices) says otherwise.

5 Likes
12

I didn’t mean to not be welcoming to newcomers. What I meant is that core contributors are more important and therefore the platform should be more welcoming to them than to the newcomers.

Most work in open source world is done by a single person, many people do not realize this. This means that in the end the sole goal is “getting things done” because if this one single person doesn’t get the chance to do the work because of too much communication overhead, then the communication was in vein. Its large corporations/societies where the efficiency of a single person decreases due to delegation of work - for them the communication overhead is justifiable because they are really able to let the work do by many people. We don’t have this luxury. The reality is already that many core contributors to Scala (as core contributor I count the people who work at the language, the compiler and the tools) have left but not enough people have joined to replace them. You can believe as much as you want that this is due to the lack of being welcoming to newcomers but as someone who sees himself as a core contributor I say that this is due to technical issues.

To go back to the topic: The TO seems to believe (as many people prior to him did) that the thing that matters most is to have as many newcomers as possible. I disagree with that. In my eyes the thing that matters most is to find the right balance between core contributors and servants that spread the word for the project out into the world (instead of servant you can also use the word user or single-time-contributor if you perceive this as friendlier). I think that having Discourse is a better choice than having everything on Github - the latter simply has its limitations that makes it less useful for projects with many users.

Not sure what you want to say with this. In reality this theoretic model does not exist, therefore I don’t see it as important to consider it in the first place.

Again, this is an issue of finding the right balance. If the core contributors are busy merging changes and guiding newcomers to produce correct changes they can spend less time in other things. Building a community is also not always a desired goal to keep a project alive.

Yes, that is what I meant.

Did you also make a distinction between non welcoming (unfriendly) environment and hard to use environment. As I said in my first post I think (but I don’t know) that most goes back to a hard to use environment.

1 Like
13

I like Discourse having used it (or drunk its cool-aid?), and I hope it’s not an excessive barrier, but would welcome data. I have no clue why Gitter would be lower-barrier than Discourse, but I find it intensely unusable — I remember @nafg made an excellent suggestion about Dotty syntax and have no clue how to find it again (OT: @nafg do you have a pointer?).

But I intensely disagree with

I used to think that, stood corrected, and became suspicious about such statements. But they ring very true because they’re extremely effective self-fulfilling prophecies: if you don’t work to remove arbitrary obstacles, the only successful contributors will be those who overcome those obstacles and think they’re no problem.

And yes, a certain set of people are determined enough. As a student I poured hours into few projects ignoring lots of obstacles. Other extremely talented devs care, especially if they’re contributing in limited free time. Most projects don’t have enough developers to be that picky.

In fact, I’m not sure arbitrary barriers can be a great way to unintentionally suppress diversity—going from “I don’t mind” to “good devs are somewhat like me and don’t mind” is the crucial fallacy. But arguing well this point would take me quite a few words and we’re already OT—for now I can only link to the excellent post http://pgbovine.net/command-line-bullshittery.htm, though explaining the link well would take longer.

14

Discourse should be seen as replacing Google Groups, not GitHub or Gitter.

As for Discourse vs GitHub Issues, I don’t think doing absolutely everything on GitHub Issues is a good idea. Issues are great for strictly on-topic, focused discussions of actionable ideas for changes to the contents of a GitHub repository. Discourse is a good place for questions, discussion, debate, announcements, and so forth. (Where exactly the line between these two kinds of talk should be drawn will always be somewhat unclear, but that’s life.)

2 Likes
15

To ensure desired usage, I suggest every Scala project needs a CONTRINBUTING.md directing users to the Discourse instance.

I posted to “scala/scala-lang#581” in good faith; I was not trying to make a point about Discourse. In doing so, I experienced exactly what I was concerned about.

I’m not sure a GitHub issue is the most appropriate place to ask this question, because this isn’t really a specific issue with the site that can be fixed. It’s more of a question/discussion that would probably be best placed on Discourse.

I am familiar with the variation of rules and conduct of communities, the risks of posting the the wrong mailing list, the importance of not violating a forum’s conventions as a new user, but had thus far happily avoided any of those experiences on GitHub. This is the first I have felt I have “done GitHub wrong.”

FWIW, I do not think that was the intention of Heather’s post.

16

I’d just like to throw in a voice of support for discourse as a replacement for google groups. Half the time when google groups show up in search results, I can’t view them without logging in inconveniently, and clearly the platform hasn’t proven friendly for ongoing discussion as most of the groups I’m a part of are mostly inactive.

Conversely, discourse has already provided a forum for a lot of interesting conversations that I’m not sure would have happened elsewhere. It’s new, and different, but so far seems good.

17

Yes, that would be a welcome contribution to the scala/scala-lang repo (and other repos as well). Something short could fit in README.md; if it gets long we could split it out.

Such links to Discourse aren’t in many places yet — most prominently, Community | The Scala Programming Language doesn’t mention Discourse yet, I guess because it’s still considered to be in a transitional/trial period? I assume the Scala Center will flip a big switch at some point and just isn’t quite ready yet.

18

True, because we’re insiders. Social reward is useful for outsiders, people unknown to the Community that acknowledge these accomplishments and are willing to reward them.

This is true, it can be seen as a barrier. But in the real world this barrier also exists. People have a tendency to trust others with more background or experience. Yes, this is not the fairest way of filtering people’s opinion, but it’s the strategy that most people follow both in the real and virtual world. And of course earning this experience is not easy. But even if our community does not care, we need to acknowledge the reality and realize that some people will use people’s professional experience to filter out ideas. I don’t particularly follow this strategy and try to separate ideas from the people that utter them, and I find that this strategy encourages a “college of equals”. But even I can fall into this bias. In fact, we all are subject to bias.

I do not have as much experience as you in this field, so I only have hypothesis based on my limited background in psychology, open-source communities and personal circumstances. I have probably overexaggerated the impact of social reward – but I’m not sold on your point that social reward has no effect (although we agree it’s not strictly necessary). Merits are important in no matter what community. This is why people invest time in open-source – to say that they have worked in project X or Y, or they help to do Z. Why? It improves their professional value, which ultimately is translated in better social and economical circumstances. I think that, to some extent, a social profile that proves a strong involvement in the evolution of the language is beneficial for users and could motivate people to participate more. We’re unconsciously influenced by the professional experience of others, one way or another, especially in topics where the right solution is not obvious and subjective. If we didn’t have Discourse metrics, people would use GitHub repositories and contributions to bias their opinions.

My view on this topic aligns with what Pieter Hintjens writes in “Building Online Communities”:

Successful on-line communities tend to be based on the contract of mutual benefit, whether implicit or explicit. That is, it is possible to build a billion dollar business based on volunteer labor, with every participant contributing for selfish reasons. Often, participants do not realize or care that they are part of a community. However, every action we take is economic. “Crowd sourcing” is the exploitation for profit of volunteer labor. And it only works when the crowd really wants to solve the problems you throw at it, or the ones it discovers.

He expands on this idea in the book and IIRC he briefly discusses social reward. Perhaps we’re wrong to consider “social” contributions (like participating in discussions and helping evolve Scala) as a thing that people would care about and reward in professional profiles. Perhaps you’re right and it only applies to technical skills like coding or answering questions in SO; but I’m not convinced this is the case. The line separating technical contributions and social contributions is very very faint, the differences between SO and Scala Contributors are not that big, and I also see a lot of altruism in this community, even though we share some terminal goals.

19

I’ll modify the “Login” button to make this more evident. Therefore. people will see that they can log in with Github upfront.

The name of Scala Contributors was chosen after our GitHub repository and Gitter channel. I think it’s very representative of what it’s supposed to happen here. But I agree that it may have a stronger meaning to people not familiar with these groups. I will think of the best way to educate people and encourage them to log in and participate in this Discourse instance. As you see, I have been doing that in my Twitter account recently.

I think that the Discourse instance is quite optimized for indexability. Searching “scala contributors” in Google ranks Discourse as the second website, one position higher than the GitHub repository. It’s true that we still need to change our current websites to point to Discourse and we plan to do this soon (thanks @SethTisue for the correct prediction).

We do have the same feature in Discourse and even more – the Discourse instance is full of cross references and suggested topics (a feature that GitHub misses). In fact, we can also link to GitHub repositories from Discourse.

Discourse allows users to have a fine-grained control over what they want to see or be notified. You have the mailing list mode, but you also have other ways of controlling the notifications. You can do this from your Discourse profile. For example, I get a notification automatically for any topic categorized in “Scala Platform”. These subscription features are way better than the ones GitHub provides, which by the way don’t work correctly from time to time (I am currently not getting notifications of activity in some repositories, when I should because I’m a maintainer).

I and others have seen such cases. Bad actors are not kept away because GitHub is used. Fortunately, we haven’t had a lot of conflicts in the repositories of our community, but I can tell that this doesn’t hold for others. In any case, GitHub is not the right tool for moderating heated discussions because control is limited and the GitHub guys don’t optimize for this use case (again, it’s understandable, it’s not their first priority).

I think that the fact that we’re having such discussion in Discourse and so many people have given their two cents is a proof of success. I agree there are some things that need to be optimized like some usability issues you’ve experienced or the way people perceive Discourse. I’ll personally take care of them. But I think Discourse is a step forward that is bringing a lot of interesting discussions to the table, and I’m again very happy to see these results.

1 Like
20

Perhaps this whole “social reward” aspect will turn out to be more important on users.scala-lang.org (once it’s truly up and running) than on contributors.scala-lang.org.

21

Hmm. I hadn’t realized that folks were trying to boot up a “users” version of this. I assume it’s an attempt to supplant the mailing lists. (?? Or am I missing the point?)

Honestly, I’m skeptical – while the barrier to entry isn’t wildly high, it’s non-trivial, especially for the general public: while it’s a safe bet that Scala contributors have GitHub accounts (and thus, easy login here), that is absolutely not a safe assumption for typical users, many of whom are working in closed corporate code bases. This is a new, unfamiliar platform, unlike well-understood mailing lists, and in my experience so far, quite a lot harder to use effectively than the extremely low-friction email experience. (Not terrible in the grand scheme of things, but not great.)

I don’t object to the experiment, but please don’t close down the mailing lists pre-emptively – I’ll be pleasantly surprised if the users version achieves anywhere near the uptake of the existing “user” media. Frankly, for typical user questions (as opposed to the relatively focused and in-depth discussions we’re having here), I think this is a fairly bad approach – harder to use than email, not as effective as SO…

22

These users can sign up with their normal email addresses just like Google Groups. And they can receive posts to their inboxes and also filter posts by tag. As soon as Fabien is back in the office, we’ll also have fixed our Discourse installation so that one can reply via email rather than having to come to contributors.scala-lang.org.

This it would be a drop-in replacement to Google Groups.

Thus I really don’t understand the handful of folks that are opposed Discourse. I see Discourse as a strictly superior replacement for Google Groups. Let’s just give it a chance :slight_smile: (it already is more active than scala-internals and several other Google Groups mailing lists, btw)

23

True, but (a) it’s new, and (b) it’s topically contentious, both of which usually give an initial burst of activity to any conversation system. I’m still in wait-and-see mode on this instance, to see whether it has legs, but I expect that the SC can keep it reasonably active simply by continuing to propose ideas to discuss on it.

More importantly, though, keep in mind that I wasn’t commenting on this instance (which, as I said, I’m okay with); it’s the “users” instance that I’m more skeptical about. My argument isn’t that Discourse is bad, it’s that it isn’t the be-all and end-all solution – it has some strengths, but also some serious weaknesses, and I expect those to bite harder when you try to use it with more-casual users. Frankly, I think it’s a bad fit to the needs of a general “users” group. So I may be wrong, but I’ll be surprised if the users instance still has a lot of activity after six months…

24

This arrangement seems to work great for Rust:

25

@nafg @heathermiller I have just enabled the “reply via email” feature. Hope you enjoy. Note that replies have to be longer than 1000 bytes. So very small replies (one sentence long) won’t pass the Discourse filter.

26

This is my attempt to say thanks in enough characters to satisfy the
filter.

1 Like