Let's close this Discourse instance

Meta Discourse
1

Herein, I propose closing this Discourse instance in favor of utilizing the GitHub Issue tracker.

As can be seen in GitHub scala/scala-dev #267 (comment), I was not sure about this Discourse instance when I first learned about it.
I have since learned more about this Discourse instance and given the platform a try.
I believe I now understand my initial reaction and that this Discourse instance (Scala contributors) would be better provided by GitHub Issues.

There are two main reason for this:

  • Moving to GitHub eliminates barriers to use which come from using a different system. This barrier is real in a number of ways.
  • GitHub has good integration with GitHub, and the rest of the Scala ecosystem is on or is moving to GitHub (from what I have observed anyway)

Many of the conversations on here concern the “Scala Platform” idea, which is not itself a work of code.
It is still an open project with artifacts and outputs that needs a home and hopes for community involvement.
As such, I do not see any impedance between its needs and what GitHub provides.
In fact, GitHub Pages is already utilized to publish information pertaining to the “Scala Platform Process.”
Perhaps that repository’s issue tracker would be a suitable home?

If the goal of this Discourse instance, is to be a single place of conversation for across projects (thus the “contributors” name), I would propose that GitHub’s support for referencing issues across projects within its platform is sufficient.

Additionally, the Collective Code Construction Contract (C4) that is being proposed in the context of the Scala community seems to support my view. Platform is previously defined as GitHub:

The project SHALL use the Platform issue tracker.

Explanation on the above requirement given in Social Architecture by
Pieter Hintjens:

[…] keeping the issue tracker on the same platform means one less UI to learn, one less login, and smooth integration between issues and patches.

2

Hey @vossad01!

I believe there are a couple of ways to look at this. If I’ve understood the reasoning behind having Discourse in the first place; it is primarily a replacement for mailing lists, some forums and perhaps other trouble-shooting solutions that have previously existed. Therefore, I’m going to assume this while I put on my Open-Minded Hat™.

Discourse is primarily a forum. Since you (one-click) log in with your GitHub account - it’s more connected to GitHub; than let’s say having meta discussions on Google mailing lists et al. Because of this, I believe it has a lower barrier than those solutions.

Layout-wise, I feel that it offers a different experience to Stack Overflow and GH issues since there’s the possibility of having meaningful discussion (without polluting issues) and solving a more intricate problems than “Why X when Y if Z?” (which usually have one clear solution).

Unlike Gitter - it is indexed by search engines, but still allows for this more casual, solution oriented discussion.

I agree with your point about “The project SHALL use the Platform issue tracker”, but I don’t think it’s a danger that someone will open issues here. To be fair some discussions here might lead to bug reports and issues being opened in the appropriate places.

When coming into a new community, it is also important to be able to quickly grasp where discussion is, where to look for information, announcements and get help, this will be difficult if information is spread out across multiple projects, all of their chosen issue trackers (be it GH or something else), IRC or Gitter. This is one of the strengths of the Rust community and their communication relies heavily on Discourse.

If you look at it this way, I believe it is a much better alternative to what we’ve had in the past. But like all things open-source, if it isn’t liked and useful - nobody’s going to use it and it will quietly fade out of existence. If that happens it should, of course, be closed.

For now, I think we should try to be positive, embrace this and if it doesn’t work out, it won’t be the end of the world :slight_smile:

4 Likes
3

Scala Contributors aims at:

  1. Creating a public identity for all the Scala contributors and the community. Important for making Scala more visible and reachable.
  2. Hosting high-level and meta discussions on several topics, not only the Scala Platform.
  3. Gathering all the discussions in one place to avoid fragmentation. Fragmentation hurts people’s engagement in discussions and limits their reach.
  4. Ensuring that discussions are moderated and complying with the Scala Code of Conduct.

The decision to open the Discourse instance was done because we consider that GitHub does not meet our needs in the most optimal way. That is:

  1. Features for moderation are limited. For example, there is no way to split topics. Previously, we were using GitHub for carrying out SLIP discussions and the experience of participating into these discussions was bad. Discussions were unorganized and scattered. People were not encouraged to continue discussions that went off-topic and with no clear thread in the reasoning. Anything that makes moderation easier is good because we cannot reach a conclusion in a chaotic debate. Among other features, we have already split several SP topics and it’s great how clear and focused discussions are now. I’m sure people appreciate that.
  2. Search is limited, there are no metrics and topics are not sorted in the issue tracker. In order to find something in GitHub, especially a discussion started a while ago, I have to devote at least several minutes looking through my email or searching the issue tracker (in the open and closed tickets). Further, not seeing the most active topics in the issue tracker makes us miss a lot of good points from people that are not aware of those discussions. This hurts us all.
  3. There is no easy access to give rights to a subset of moderators, especially for already existing repositories and organizations. Further, if you want more complicated setups, GitHub does not support them. You will always end up with ugly workarounds with no logical sense, like giving membership to people that are not related to the development of a project just to moderate discussions. I’m sure we can do better :slight_smile: .
  4. There is no social reward for participants. Social reward is very important to motivate and engage people to participate in discussions. In Discourse, people earn badges and points and create a social profile that is the proof that a user is (or has been) very active discussing Scala-related topics. IMO, StackOverflow nails social rewards and this is one of the main reasons for its great success.

I’m probably missing some points, but these are the main ones. Discourse is a forum and solves a different problem than GitHub. GitHub is a platform for building and managing software. Discourse focuses on increasing participation and enhancing the experience of discussions. Before coding, we need a plan and consensus. Having two different platforms for different problems makes sense to me. Managing Scala and its evolution is more about open, high-level discussions optimized for the Scala audience.

That clause of C4 only concerns the issue tracker and the project management, in this case every Platform’s module. It does not apply for this Discourse instance, which is not meant to be a discussion place for the Scala Platform, but a vast array of topics related to the evolution of the language.

Rust Internals uses Discourse and has been very successful. In my opinion, this is an example to follow. It’s food for thought that Scala is more widely used than Rust and yet our community and involvement in the evolution of the language feels smaller. The fragmentation and the low activity of our mailing lists seem to prove my point. Discourse is our attempt to change this, and I’m very happy with the results that we have so far!

4 Likes
5

Brief digression – sorry, but we’ve wandered into my specialty. (My career is largely about online collaborative systems, and I’ve built a bunch of these forum environments.) I generally agree with @jvican’s points, but one note:

In this context, specific to technological social rewards in this particular community, I disagree.

Artificial social reward is powerful and useful in certain environments. It’s critical in Facebook, because Facebook has little other point. It’s extremely helpful in StackOverflow, because SO is a fundamentally altruistic platform, where people are doing a favor to questioners and the community by helping with the search for answers – the social rewards acknowledge that altruism quite explicitly and deliberately.

But in a focused, collaborative, goal-oriented community like this, that’s not nearly so obvious. We have a collective goal, we more or less understand what it is, and that’s largely its own reward. We know who is being helpful. The social reward mechanisms built into Discourse are pretty artificial and beside the point.

Indeed, I’d say that most of the major social-reward systems are inappropriate here, for the same reasons they cause problems in SO. A common complaint about SO is that, while it’s great for experienced answerers, it kinda sucks to start out in – until you’ve worked your way through the initial hoops, you feel pretty disrespected. A lot of people give up helping on SO before they really get into it because of this barrier to entry. We don’t want that here: we really, really want to broaden the community involvement here (I believe), and one of the better ways to do that is to promote a “college of equals” feel to the thing.

More generally, we don’t need social rewards, because we’re a smaller community. Frankly, at this point we mostly kinda know each other, or at least get to know each other’s online presence fairly quickly. Social rewards are critical for huge online communities like FB and SO because of scale: they’re huge and relatively anonymous, so you need a reified mechanism of social reward in place of the simpler and more intuitive mechanisms that come automatically in smaller social circles such as this one.

None of which is to say that Discourse is the wrong answer: while it’s not perfect (I despise the threading UX here), I don’t have a better suggestion, and think we should stay here at least for the time being. But don’t oversell the social rewards aspect: IMO, they’re at best neutral, and are arguably flat-out inappropriate for this particular group…

1 Like
6

Not disagreeing with anything, just wanted to make two small points, (1) Gitter is indexed and I have many times found helpful exchanges in the archives, and (2) I really wish you could use Discourse like a mailing list, i.e., reply via email. Google Groups and GitHub issues both support this.

1 Like
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…