Alternative to Mailing Lists

[HaloFour]

Given #16905 there is a bit of concern over the migration of language proposal and discussion from GitHub to mailing lists. I don't have the full list of reasons as to why this migration was announced, however it sounds like primary reasons include the difficulty in managing tasks mixed with discussion in GitHub and the lack of threaded discussions. The purpose of this issue is to track the goals and features of the interested parties to determine if there might be better options.

@eyalsk has started a SurveyMonkey poll where you can vote for your primary or secondary preference between Github, Discourse, mailing lists or "other". If you feel that "other" would be a better choice feel free to elaborate on this issue or here. Results can be found here.

Goals

1. Easily manageable and separated from project work items.
2. Approachable by interested casual users.

Features

1. Web interface
2. Email integration
   1. Can subscribe to email notifications
      1. All discussions
      2. Per topic
      3. Per thread/discussion
   2. Can send email to create new discussion
   3. Can reply to email notification to comment on discussion thread
   4. User email addresses not exposed to other users
3. Threaded discussions/comments
4. Tags/labels
5. Mentions (@user in GitHub)
6. Rich formatting
   1. Markdown preferable
   2. Syntax highlighting in code blocks
7. Searchable, by
   1. content
   2. author
   3. state
   4. comment
   5. tag/label
8. Quick reactions / likes
9. Emoji
10. Cross-links

Update 1:

1. Changed "Quick reactions / emoji" to "Quick reactions / likes" as by "emoji" I meant the 👍 or 👎 reactions that we can apply to Github issues
2. Added "Emoji" as a separate line item, for 😸, 💩 or 🍝 that can be littered into comments.
3. Added "Cross-links" for references between issues and/or other mentions, like PRs.

Update 2:

1. Added link to SurveyMonkey poll for alternate discussion platforms

[AdamSpeight2008]

The new repo should be used for discussion / designing features for those language. We should layout a basic framework for contributing a proposal, some basic guideline and rules.

When a feature is deemed worthy to be presented to the LDM a proposal is made in the main (repo), by a trusted community member(s) only. The LDM can ruminate over the proposal, and any feedback can be pass to respective language design repo. Discussion on the feedback is in the respective language repo, not Roslyn. Thus;-

Roslyn Repo tracks the progress of "viable" proposals, Language Repo tracks the progress of proposal in the "back of the envelope` stage. Note: LDM Member are not required implicitly to subscribe to these issues.

Humbly as an example, you only need to look my closed issues and PRs, to see the what should have be mitigated.

If a language proposal first appears on Roslyn we should politely redirect them to the correct language repo and close the issue. This must apply include core members of the design team. We know who you are.

[AdamSpeight2008]

@jasonmalinowski whilst you're in the Projects section, would you mind if you could you put some of the Feature Requests into one or two (for C# and VB). Just to get some initial feedback on it's potential.

[benaadams]

Discourse? http://www.discourse.org/ is mailing list, discussion forum, long-form chat room - just a shame they went with Ruby; otherwise would have been 💯 😛

[alrz]

@benaadams Yup, I just moved my comment to https://github.com/dotnet/roslyn/issues/16905 since not everybody subscribed to this thread. :)

[alrz]

It's the one that Jeff Atwood (codinghorror.com) works on (former .NET developer).

I wonder what "mailman" went with. Assembly?

[benaadams]

We use Discourse; would recommend; and works with Github logins. Though our user interaction isn't as wild as Rosyln; but has all sorts of features http://www.discourse.org/about/ including operation via email, so people that like mailing lists can pretend its just a mailing list 😉

Can also integrate it with the comment section of the blog posts; have a private section if you need something NDA/MVP's; bring in all the dotnet mailing lists and then all of the discussion is happening in the same place, even if its happening at disparate properties (like blog posts)

Think has the the full list of requirements outlined by @HaloFour

[orthoxerox]

@benaadams What's wrong with Ruby? Discourse can always join forces with GitHub and spend a few million on JRuby or Crystal if they don't like wasting megawatt-hours on yarv, like FB did with php.

[DavidArno]

@alrz,

Not sure they had assembler when mailman was created. I think it's programmed by swapping valves in and out.

[benaadams]

@orthoxerox nothing's wrong with Ruby; just would have been icing on the cake if it was C# or VB.NET for discussing the evolution of those languages

[alrz]

just would have been icing on the cake if it was C# or VB.NET

FYI: here is a blog post on that.

Since they've hosted mailman's Python, I think that would be no trouble to host discourse's Ruby.

[jnm2]

Discourse was my immediate thought when I first read about the move.

In response to the LDT's desire for threaded conversation, that's traditionally mutually exclusive against the ability to scroll down and take in an entire conversation, but Discourse is one of the few things that finds the best of both worlds.

https://blog.codinghorror.com/web-discussions-flat-by-design/

https://meta.discourse.org/t/threaded-vs-flat-discourses-way-of-handling-responses-is-genius-but-i-have-one-small-suggestion/4053

[iam3yal]

I'll repeat what I said before at #16905 because @MadsTorgersen wrote we should write our suggestions here so what I'm proposing is pretty simple:

The design team already created two repos for C# and VB.NET so I think that we can just move the design discussions to these repos and do what we always did, only that when a proposal is accepted then someone from the design team would have to tell the person to send a PR.

The community can still discuss the proposal at the original issue that was created, the PR can be updated based on the design decisions that are made and that's it.

I really don't see a reason to move from GitHub and I think that the same process that applies to the development of the software's codebase can be applied to the development of any other content and managing proposals isn't an exception.

The process can be iterated on and improved but anyway, if the suggestion I made isn't acceptable Discourse would be my second choice.

[alrz]

I agree with @eyalsk, it is the most natural move without any dramatic changes to the platform or anything, however, the team specifically raised concerns regarding administration and management; there would be no difference if we just move the discussions over to another repo.

I think the requirements should be laid out by the team themselves and then viable options could be discussed. I thought about a community-moderated repo (or even "moderator" users in Discourse) but that doesn't seem to be a straightforward approach as there are a lot other aspects that could come up.

Either way, I wonder how existing proposals are going to be migrated to the new repo/platform to be assigned to active, adopted, or rejected lists? They are already labeled as backlog, planning or ready, but the new categories are quite different.

[bondsbw]

GitHub issues aren't great for design. The only appeal I see is the current community which exists here. Though I don't even find that argument compelling... it's easy to sign up for other services.

[alrz]

Aside: rust is also going to drop issues for language discussions.

https://internals.rust-lang.org/t/the-rfc-issue-tracker/4723

[orthoxerox]

There are two groups of people that we should try to accommodate.

The language design team wants/needs a convenient medium to discuss the minutiae of (very) promising proposals. There's going to be lots of back-and-forth comments, questions and agreements between decision makers. This is their actual job, so they should use whatever they want.

We, the outsiders, want a convenient medium to mainly watch these discussions from the sidelines, but we also want a place to discuss and classify the backlog of ideas, preferably with someone from the design team pitching in.

The problem with the current (lack of) solution is that the mailing list is not a good place for the backlog. The proposals are kept in the repo, but adding something to it (even if there's a separate folder for the untriaged proposals) is a much more daunting task than starting a conversation on the tracker: first you have to subscribe to the list, then pitch your proposal there, then rewrite it as a PR and send a link to the list, then discuss it on the list again. An outsider will not be able to smoothly join the process.

[iam3yal]

@bondsbw

GitHub issues aren't great for design.

This doesn't make sense to me, do you mean discussions?

The only appeal I see is the current community which exists here.

Why do you think it's the only appeal?

Though I don't even find that argument compelling... it's easy to sign up for other services.

You see, unlike you I think that GitHub is a great place for discussions.

Signing up to another service is obviously not the problem, the thing is why do we even need to sign up to another service if it works perfectly fine for us here? well, at least for some of us but if it doesn't work for you then I think that it would better to write what exactly doesn't work for you.

Now, I don't say that GitHub is perfect and I don't mind sign up to another service but I think that like @alrz said the team should be crystal clear about the intents and requirements and what exactly are the problems for them so we can have a fruitful discussion about it.

[benaadams]

@orthoxerox Third group also: which is raising and resolving issues directly related to the the code in this repo.

[orthoxerox]

@benaadams Well, if we leave they will have the tracker all to themselves. I don't think the compiler team will be inconvenienced by that.

[bbarry]

In case anyone happens to have not been paying too close attention, https://internals.rust-lang.org/ is a discourse forum largely being used for the same purposes these mailing lists are being intended for.

I think that community, while significantly smaller in terms of general users probably has a far higher % of users participating in the online communities (the rust subreddit is about 2/3rds the size of the csharp one and the rust github has maintained similar activity to what roslyn has had this year since 2011).

[alrz]

The language design team wants/needs a convenient medium to discuss the minutiae of (very) promising proposals. There's going to be lots of back-and-forth comments, questions and agreements between decision makers. This is their actual job, so they should use whatever they want.

We, the outsiders, want a convenient medium to mainly watch these discussions from the sidelines, but we also want a place to discuss and classify the backlog of ideas, preferably with someone from the design team pitching in.

@orthoxerox That's exactly how discourse would work, since it does have a mailing list mode, anyone can opt-in to emails, while outsiders could use the web interface. The proposal process remains as-is as mentioned in dotnet/csharplang repo, just change the first step to link to the discourse instance.

[bondsbw]

@eyalsk The GitHub issue tracker seems built for a relatively small number of issues, since its query capabilities are weak (as discussed already). The C# language has a huge community which will only grow larger if the language continues to prosper. Certainly this will also result in more involvement and more proposals.

GH issues are great for short, focused threads (e.g. "this is obviously a bug, go fix it"). They also have good integration with code, pull requests, commits, etc. That's the sweet spot. But none of that really applies to language design; the best proposals always have multiple threads of discussion about different aspects of the proposal and become quite difficult to follow.

OTOH, markdown/code snippets are a good aspect. Tags (for categorization) and reactions (for voting/approval) are also nice. I wish those worked on mobile as well as on desktop.

[alrz]

While discourse is the only alternative that is being suggested so far (beside csharplang issues), I'm not convinced yet that it could be the "best" choice, considering how discussions were going on so far on this repo, discourse lacks a feature that might be crucial for managing issues that often have had opened here on GitHub, for example. discourse does not link and back-link threads to each other like GitHub does for issue links. That's actually quite useful for handling duplicates among other things. But that's about it. It's well-equipped in every other aspects. EDIT: I'd be ok with url links though. Just to point out that there is this lack of feature.

[iam3yal]

@bondsbw Maybe we can take some of these concerns to the GitHub team and maybe they will improve these things, not just for the Roslyn team but for everyone else.

I really see no reason to change if anything I see an opportunity to improve GitHub.

[bondsbw]

@eyalsk Sure, and on the other thread @Haacked mentioned that these issues are known by the GH team and that feedback supporting improvements is welcome. And I'm all for that approach.

I'm just not sure when such changes would make it in. Before we hit 20K issues? 30K? 50K?

[iam3yal]

@bondsbw I hope it will be soon but really I dislike the other options and GitHub just grew on me.

[jnm2]

To @eyalsk's point, they urged us to just give mailing lists a chance. I would have urged them to go halfway initially and just give GitHub a chance for a few month with the isolated repo which is a great idea, while working with GitHub and perhaps Discourse for some more permanent solution. As they said, the picture does change when there's only one repo where everything is just their stuff.

Discourse seems to be the closest thing we know of, but it does have some disadvantages. The one that comes to mind is automatic crosslinks with GitHub issues, PRs, and commits. Something tells me that an integration between GitHub and a Discourse extension would be difficult but incredibly valuable if pulled off, for every development team everywhere. Or even better, if GitHub had the resources to evolve to keep up with the LDT's needs, the world would just get better for everyone.

[riking]

discourse does not link and back-link threads to each other like GitHub does for issue links

You mean like the stuff right below the first post here? https://meta.discourse.org/t/what-do-user-trust-levels-do/4924 Those crosslinks are site internal only - I don't think Github lets you do backlinks to an external site right now.

I'm actually rather surprised - I read the issue description here and said "Uhh, isn't that just a goals & feature list for @discourse?" (with the exception of 3). Discourse's features still leaked into my habits - I half-expected quoting a comment to insert a back-link into my post.

Disclaimers: I came here from a Twitter thread; I've contributed to the Discourse project.

[alrz]

You mean like the stuff right below the first post here?

Are they the threads that explicitly link to the current thread? I meant something like this. And that's not the only one. Discourse Markdown is standard meaning that it lacks features from GitHub flavored Markdown, like tables. I'm not sure if any of this is important to the community but just that it doesn't exist might be inconvenient for a seamless transition.

Since GitHub worked out well so far, I'm actually skewed towards csharplang issues rather than moving to another platform which will have its own trade offs, unless the team really needs something else. However, with separated repositories, the existing features might be now sufficient.

[miloush]

If I had to chose between mailing list and Discourse, it would be mailing list.

[iam3yal]

@miloush Can you explain the reason for it?

[HaloFour]

I added "cross-linking" onto the list of features. It had slipped my mind and I agree that it's a nice feature to have in Github. I also split "reactions" and "emoji" into separate features.

Looking at the issues on this repo a little over 10% of them, or 1100, seem related to language design. That's still a relatively significant number, possibly more than would be reasonable to manage in Github with the current functionality.

Whatever it is, the features towards the top of my list include:

1. Web interface, so that I can peruse the list from anywhere easily
2. Email integration, so that I can be notified of discussion for proposals in which I am explicitly interested
3. Rich formatting, to easily include code snippets
4. Searchable, to be able to identify related proposals

My biggest complaints around the use of mailing lists:

1. It's all email.
   1. I have never treated my email clients as a permanent repository for long-lived discussions. I regularly purge every notification I've ever received from other forums. I really don't want to have to maintain every email from every discussion buried in my email client.
   2. Between gmail and Outlook 2016, neither provide an easy way to manage these discussions. Both just lump all of the emails within a conversation into a large lump ordered chronologically. The only place I see "threading" is on the mailman archive, but only within a calendar month.
   3. After a few replies each email becomes more reply than new discussion. Anyone who's ever been forwarded a long email chain should be well aware of this mess.
   4. Email clients are awful for writing ad-hoc code snippets. The first few proposals I posted there were held up as demonstrations as to the formatting capability of the mailing lists, but the only reason they were nice is because they were copy&pasted from Github. So, in short, I'd have to use a separate markdown editor. All it takes is for one bad reply to shred the rest of the discussion into plain-text. And the archives are nothing but plain-text.
2. It's all or none.
   1. I am forced to receive emails for every discussion, regardless of my interest in them. I don't care about the vast majority of issues on Github, including language proposals.
   2. Short of adding new filters to my email client there's no way to silence notifications about a proposal.

[iam3yal]

What if the community will come up with a system that sits on top of GitHub and provide all these features? I think it's doable.

I'm not sure whether GitHub APIs is that rich and whether it will allow for all the scenarios above but if so maybe we can do it ourselves, the question is whether the Roslyn team see themselves using it? what the community think about it? :)

[alrz]

That's quite a list. I think we should choose something and settle. Maybe the developers behind it could improve it (which won't happen immediately) but anything else seems unrealistic. The mailman is on fire.

[HaloFour]

@alrz

I figure we wouldn't cover them all. I wanted to capture as much of what we like about Github as well as the features it lacks which may be driving the desire to move away from it. I wish I could've been a fly on the wall for those debates which led to the decision to move to mailing lists as that would provide much better context.

Discourse largely sounds like it would be the best contender. I personally don't have experience with it. If it can behave like a mailing list and those people who want mailing lists can just subscribe to it and receive proposals as emails and replying to respond. They wouldn't need to care about what the server platform looked like.

I mentioned this whole mailing list debate to my wife. She's a professor at a large university and they use mailing lists for a lot of purposes. She thought that the idea of moving to a mailing list was awful as they work fine for individual posts that don't elicit replies, but not well at all for discussions given the amount of email it generates and how easy it is to lose a thread.

[iam3yal]

BTW, they already start to push people to use the mailing list! this is such a disappointment. 😢

[jnm2]

What if the community will come up with a system that sits on top of GitHub and provide all these features? I think it's doable.

Like ZenHub did?

[iam3yal]

@jnm2 I'm not familiar with it but maybe? :)

[jeroenheijmans]

I'll be short, and not repeat my entire comment from the other thread but just summarize it.

As a casual (normally) read-only consumer of discussions about language features, you would probably loose me (and like-minded folks) entirely if you move away from something as easily accessible as GitHub issues or Discourse and to mailing lists.

I realize the system used must first and foremost cater to core maintainers and highly interactive users, but still, where possible I would appreciate my position to be taken into account as well. If that's not possible: no hard feelings! I appreciate you guys are doing all the hard work.

Thx for the discussion, and thx for being open. Keep up the good work!

[MattDillard]

I'll chime in as another one who has followed the language discussions on a nearly daily basis for the last few years, but has never piped up myself. My enthusiasm for the language has grown over this period of time. I have no interest in following future discussions if they are moved to a mailing list, however. My absence may not affect the core development team, but it will certainly dampen my enthusiasm and have a trickle-down effect on those in my sphere of influence.

Please keep these discussions on GitHub, Discourse, or any comparable platform. You are losing more people with this move than you realize.

[Thaina]

I was understand the decision. But do you think what will happen to people come and write new idea as issue? Will you need to go check and close all of it one by one?

Language design repo would be better idea since it more familiar to do in github

[alrz]

BTW, they already start to push people to use the mailing list

No surprises. To MS, GitHub represents a small fraction of the actual user base. I'm largely relying on @MadsTorgersen's https://github.com/dotnet/roslyn/issues/16905#issuecomment-277336151 for this discussion to move forward. However, I see @gafter or @jaredpar are pushing on using mailing list to pass through new and existing proposals. Wouldn't it make sense to keep that decision on-hold until this issue has been resolved?

[iam3yal]

@alrz Exactly my thoughts, it's really irritating and sad to see them pushing people.

@MadsTorgersen you told us to share our thoughts here, well, we did and yet no one from the team joined the discussion and tell us where you guys are going with it.

You can't push people and tell them to move into the mailing list, you want to try it out? do that internally, mailing lists aren't really community friendly so please don't force us into it!

Thanks.

[CyrusNajmabadi]

we did and yet no one from the team joined the discussion and tell us where you guys are going with it.

Guys, it's sunday at 3:24am in Seattle. You're not going to have many people discussing this. On top of that, as i've mentioned before, many people who would be interested in discussing are simply completely focused on actually trying to ship the next version of C# and VS. If you get frustrated because you're not seeing a high level engagement, then i'm just going to ask if we all can take a breath and give things a little time?

I'd really lke us to be able to drive toward a great resolution for everyone. But that's not going to happen in the next five minutes. It's probably not going to happen in the next 24 hours. Until the plan actually changes, people are going to follow what was laid out so that we can have a single system and process for doing things.

--

Seriously, it's a really nice weekend. Let's just all have a nice time. Potentially watch a superbowl (if that interests you). And then just talk together in a friendly manner about this next week? As i mentioned in the other thread, if this doesn't end up being a good idea literally every one on the team is willing to change things to make it better. It's not like we're selecting a communication medium and then stating that this is sacrosanct and must be the way we do things till the end of time. It's literally just the opposite. We're trying things out so that we can know first hand the pros and cons. We can then make the best, most informed, most hands-on experience to then take the next step. And the next step. And the next step.

A long time ago, there were people who were adamant that a pure github approach was how things should be. So we tried that approach out. But even now, it's clear to the team, and several people who've even chimed in here, that they can see the problems and that change may be a good things. So let's try things out. Let's be open to trying things and validating if they can work or not.

Thanks all, and I look forward to talking to you more next week.

[iam3yal]

@CyrusNajmabadi Fair enough.

If you get frustrated because you're not seeing a high level engagement, then i'm just going to ask if we all can take a breath and give things a little time?

I just think that team members can wait a bit and be patient with the community until a final decision has been made.

that they can see the problems and that change may be a good things. So let's try things out. Let's be open to trying things and validating if they can work or not.

I don't mind trying things out but like I said in the other post and I realize it's not a fact but an opinion I think that mailing list is the worst option whereas Discourse was a better place to start.

[orthoxerox]

@CyrusNajmabadi I hope it's not our lamentations that're keeping you up all night. :grin:

[bondsbw]

@CyrusNajmabadi

many people who would be interested in discussing are simply completely focused on actually trying to ship the next version of C# and VS

This does seem like odd timing to make such a drastic change in procedure.

[svick]

@CyrusNajmabadi

So let's try things out. Let's be open to trying things and validating if they can work or not.

I think this approach is part of the issue. You shouldn't be doing high-risk experiments with your community, because the end result is going to be fractured discussions. (I guess you didn't realize it was high-risk before, but you do now.)

You wouldn't do anything like this with language design, why do you think it makes sense for "community design"? (Yes, "breaking changes" are more acceptable when it comes to community, but they still have a significant cost and you should avoid them if possible.)

As it stands, it looks like the end result is likely to be:

1. Old discussions are on CodePlex.
2. Recent discussions are on Roslyn issues.
3. Current discussions are on the mailing lists.
4. Future discussions are on whatever is chosen as the replacement.

That's not a good situation to be in.

If you (the team) think that it's likely that the mailing list is not going to last very long, then I think the right approach is to go back to Roslyn issues while reevaluating the options and then do a switch the community is okay with.

If the end result is that you choose something other than mailing lists (as I hope you will), then this will cause less fracturing (net positive).

If the end result is that you stay with the mailing lists, then will cause just a small delay of truly switching to them (small net negative).

[CyrusNajmabadi]

I just think that team members can wait a bit and be patient with the community

No one is trying to be 'impatient'. They're just taking the plan of record and going with it. Again, expecting things to change on a dime is unrealistic. We'll certainly be assessing things and working to determine what the right next steps might be (including possibly doing nothing). But, in the meantime, some people are just going to do what we said we are going to do. Even if we wanted to change that it would still take time. Again, it's the weekend. People have families. People go do things. I'm only discussing things because i'm waiting for some hard drives to be rebuilt and i have a few minutes before the superbowl.

I get that emotions are running very hot. But please realize that any change (even change you want) is going to take a little bit of time.

[CyrusNajmabadi]

I don't mind trying things out but like I said in the other post and I realize it's not a fact but an opinion I think that mailing list is the worst option whereas Discourse was a better place to start.

We will consider that.

I appreciate that you recognize that these are matters of opinions. And, as far as opinions go, there are very different beliefs out there. For example, many people who work in this space directly have good experiences with mail, and have found the Github approach to be quite painful (despite the 'opinions' of some that Github would be great for this sort of thing).

I think people need to recognize that there's very likely no perfect solution. Heck, even moving to something non-github will certainly just be a deal-breaker for some who only want to do language design here. :)