Roslyn: Proposal: Move C# and VB language design discussions to their new GitHub repos

[MadsTorgersen]

Proposal: Move C# and VB language design discussions to their new GitHub repos

We recently moved C# and VB design efforts to new csharplang and vblang repos, and attempted to move discussion onto mailing lists.

A couple of aspects of this did not go over well:

1. We didn't consult the community before making the change
2. Many people were appalled at the choice of mailing lists for discussion

Once again, apologies for both, and thank you very much for lots of constructive feedback!

This is an attempt to address these by proposing a different discussion venue (2), and asking the community for input on it before enacting it (1).

Balancing time for feedback with the need to fix the current broken state, I would like to act on this proposal and any ensuing suggestions and ideas on Friday Feb 10. If there is significant discord or objections, I'll wait longer to have it resolved, but absent showstoppers I';; put this into effect on Friday.

Please respond on this issue with approval, constructive disapproval and suggested improvements by Friday Feb 10!

Options

The LDT met today to discuss which avenue to take. The options on the table seem to be:

1. Continue with Mailman
2. Use another mailing list
3. Use a Discourse site
4. Use GitHub issues

1. Mailman

I think a lot of us had a bad experience specifically with Mailman: clear text passwords, fickle threading and "reply all" behavior, unwieldy archive interface and more. Some of that could probably be remedied through configuration, or waiting for Mailman 3.1 to come out, etc. But it's not a great starting point. Also, see #2.

2. Other mailing list solution

The quality of a mailing list experience depends a lot on the email client people use. Based on the feedback it has become clear to us that a lot of people aren't nearly as email driven, and don't have access to good hierarchical threading, etc.

Also, mailing lists don't offer Markdown support, topics and individual replies aren't easily linkable etc.

3. Discourse

Some of us took Discourse for a ride, and it seems to be quite a good experience. They support Markdown, have a decent mailing list mode for those that prefer that, and have threaded discussions with great quoting functionality (though seemingly not hierarchically laid out, so you can't ignore side threads you don't care about). Also, they seem to track where you got to in a discussion, so you don't have to "find your place" again when you come back in again.

4. GitHub issues

GitHub issues are really a mismatch for free form discussion: flat discussions without threading and a lack of ability to track where you got to both make it bewildering to try to keep up - or come back to - active discussions.

Also having discussion mixed in with work items seems to create noise for both. That can be mitigated through labeling, but only if someone sits at the front gate diligently labeling all incoming. The mail notification system is getting better but is still bewildering, and search is lacking.

On the other hand, issues let you have your discussion right inside the project repo, have easy cross linking with pull requests, support exactly the same Markdown as source files, etc.

Proposal

The Language Design Team recognize the upsides and downsides of all these approaches. With one or two notable detractors, who shall not be named, we are ready to rule out mailing lists as our discussion venue: they have proved to unwieldy and exclude too many people. We think that, on its own, Discourse is probably the best discussion forum experience, and it's a great open source initiative that deserves to flourish.

However, the close integration of GitHub issues with the rest of the project repo wins out for us.

We will keep pushing GitHub to improve the discussion experience. @Haacked's comments are at least somewhat promising. But we can't bank on that, and have to find a way to live with GitHub as it is today.

Separation of concerns

One thing is to clearly separate "work items" from "proposals". We want to be able to have a clean view of:

• "debt" around the _state_ of the repos, as in design notes that need to be cleaned up, broken links that need to be fixed, proposals that aren't clear or need better examples, spec defects, etc.
• "discussion" about the subject matter of the repos: C# and VB language design: Feature suggestions, scenarios that it would be great to try to address, improvements to existing suggestions, etc.

We propose to use labels to clearly distinguish these two. The LDT will take it upon ourselves to slap the right label on all incoming. We will put query links on the top level README so it's easy for a newcomer (or anyone) to just see discussion or just see debt.

We will close work items when the work item is done. A discussion is rarely "done" - at least there's often no single triggering event where it's obvious that the discussion is over. Instead they often peter out, and sometimes are even revived. For this reason, we won't normally close discussion issues. Instead, if you want to see what's moving, sort by recent activity.

Discussion threading

We can't really do much here, except state a few recommendations to site users to keep the discussions more navigable:

Exercise strong preference for starting a new issue rather than respond to an existing one when

• What you have to say doesn't strongly fit under the title of the current issue (going off-topic)
• Your response goes into a deeper level of detail on a subtopic (double-clicking/rat-holing)
• You are proposing one possible solution to the problem described in the current issue (which will warrant separate discussion)

Just linking back to the original topic will establish the connection both ways, as it shows up in the original topic when you do.

The risk of this is higher fragmentation, which can lead to the same discussion repeating itself on multiple issues. But the reward is that threads are more on-topic and "slosh around" less, for the benefit of the reader.

Do you really need to say this?

Is it adding value that you put your words out there, or can you make the discussion more approachable by just expressing (dis)approval via thumbs-up/down to another message?

Call to action

Again: let us know _by Friday Feb 10_ if you have concerns or suggestions for improvement over this approach.

Once we move over, please engage in the new repos, and help us encourage good behavior and an approachable site that is welcoming and navigable to old timers and newcomers alike.

Thanks!

Mads

[NickCraver]

I just wanted to say thank you. It's a pleasure to be able to follow these on GitHub, but more so the handling of strong community feedback was just extremely well done here.

[AdamSpeight2008]

I'm currently using the VBLang repo (on github) to suggest features for vb.net, and even submitted a proposal. So the split is working for me. I'd be happy with continue to use GitHub, or Discourse. Mailing list is off the card for me, as email is too distracting ooh shiny

[hishamhm]

Also having discussion mixed in with work items seems to create noise for both. That can be mitigated through labeling, but only if someone sits at the front gate diligently labeling all incoming. The mail notification system is getting better but is still bewildering, and search is lacking.

Some projects have separate repos for language design discussion/proposals. Rust and Haskell are examples:

• https://github.com/rust-lang/rfcs
• https://github.com/ghc-proposals/ghc-proposals/

[MadsTorgersen]

@hishamhm: Yes, we actually discussed two repos, but I forgot to include it above. Thanks for reminding me.

Two repos does the trick, but then we're back to separate sites. poorer cross-linking etc. Ideally I just want a "Discussion" tab next to "Issues" and "Pull Requests" in GitHub! (@Haacked, are you listening in?)

On balance, the LDM preference is to stick with one site, but it's definitely something we'd love to hear arguments on.

[HaloFour]

For people who just want a bird's eye view I wonder how much effort would be needed to script scanning the Issues based on tags and periodically update a page on the Wiki which can be linked from the Wiki. Could construct something like a series of kanban boards broken down by potential language revision (e.g 7.1, 8.0, future). Either way, some quick roadmap that doesn't require the user to rely on navigating the search features for themselves.

[chrisaut]

Thank you for responding to the criticism.

I agree with your preference for Github first (not the Roslyn repo anymore) and discourse second.

I hope Github will eventually add some sort of separation of issues so that general discussion and formal proposal could be separated by users themselves rather than relying on admins to label things appropriately. Perhaps allowing users to apply certain tags by themselves would be enough.

Looking forward to continuing to stay informed and discuss the future of .NET.

[svick]

While overall I agree that GitHub is the better choice here, I think it's worth pointing out that Discourse has better tools for maintaining discussions. For example, when a discussion gets unwieldy, moderators can move the related posts to a separate topic. So users wouldn't have to know when to start a new discussion, moderators could do it for them.

[jnm2]

While overall I agree that GitHub is the better choice here, I think it's worth pointing out that Discourse has better tools for maintaining discussions. For example, when a discussion gets unwieldy, moderators can move the related posts to a separate topic. So users wouldn't have to know when to start a new discussion, moderators could do it for them.

@Haacked... open source maintainers worldwide would love this. Just sayin.

[DustinCampbell]

Ideally I just want a "Discussion" tab next to "Issues" and "Pull Requests" in GitHub! (@Haacked, are you listening in?)

The very thought puts tears in my eyes! :smile:

[int19h]

Why is there poorer cross-linking with separate repos? From my experience working with several related repos, GitHub is actually very good at handling cross-links. You can even close a bug in one repo by a commit in another repo (just use the full URL to the bug after "Fix" - it even prettifies the link in the description, so you see something like "Foo/Bar#123").

[DustinCampbell]

To be fair, I don't think there's going to be a lot of fixing bugs in other repos from this one. :smile:

[HaloFour]

I'm torn. Discourse seems like the better medium specifically for discussions, however there is something to be said about having the discussion and the proposals in one place.

I think that just by moving the language design discussion out of the roslyn repo will have a massive impact on the ability to track issues. For people who prefer to track discussions by email it immediately lets them filter and organize the notification emails accordingly. I almost feel bad for the VB.NET discussion as I foresee at least an order of magnitude less traffic there, although many of the proposals would likely apply to both languages, at least conceptually. Is it really necessary to separate the two?

As for improvements to Github, non-exhaustive and in no particular order:

1. Discussions tab
2. Track an optional parent comment for each comment
   
   
   
   1. Web interface would display a Reply button for each comment which would open a new comment editor and establish that relationship
   
   
   2. Replying to an email notification about a comment would establish the association between the two comments
   
   
   3. Web interface would list how many replies each comment has
   
   
   4. Web interface could provide two options for viewing the comments on a discussion/issue, chronologically (as it is now) or threaded, where replies are displayed inline and nested under their parent comments.
   
   
3. Better mailing list support
   
   
   
   1. Each repository automatically creates a set of email addresses to which new issues or discussions can be posted
   
   
4. Versioning of issues/discussions/comments
   
   
   
   1. Can see that the issue/discussion/comment has been modified and view the version history
   
   
   2. Placeholder for deleted comments
   
   
   3. Perhaps setting to disable editing/deleting after a certain duration?
   
   

[hughbe]

It's good to see the mailing list flip-flop. I thought I'd mention a decision made by the Swift team today - they're moving to Discourse, from mailing lists

There has been a tremendous amount of participation on this thread, with some extremely thoughtful analysis of how the mailing list serves the community and the tradeoffs of moving to a forum, like Discourse.

I've been thinking about the points made on this thread as well as looking at the experimental Discourse setup that Nate Cook provided. While there are tradeoffs with moving swift-evolution to Discourse, I think the benefits outweigh the negatives.

After discussing this with the Core Team, the decision is to move swift-evolution and swift-users to Discourse. I will also bring it up for discussion on the -dev mailing lists to do the same there, so that we all are using consistent infrastructure.

No rollout plan has been established yet. People are busy, and there are a variety of logistics to figure out. My intent is to engage with a handful of people across the community on helping with the transition, including making sure we configure Discourse properly so we have the best experience for those who want to continue to use email. We also want to import the history of the mailing list as well so that we do not lose valuable conversation. As a rollout plan gets figured out it will get communicated.

I realize that many people aren't following this thread anymore, so I'll send out a separate email just so people don't miss the decision. Thank you all to EVERYONE who participated in this thread and expressed an opinion.

Ted

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031655.html
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031657.html

[orthoxerox]

Either a separate repo or a Discourse forum will work for me. Thank you for listening to the (not always kind) pleas of the external community.

[ErikSchierboom]

Great to see you responding to the community feedback! While Discourse is arguably the better discussion forum, I think it still makes sense to just have the discussion here, on GitHub. That way, the proposals and discussions can easily link to each other. Having the language design/discussions be separate from the Roslyn project would greatly help in removing the clutter, so perhaps issues will not be as hard to find and track on GitHub as one might expect based on the current situation.

The best option I think would be to have two GitHub projects:

1. One for discussion new features or features under development
2. One for keeping track of the approved and completed language features

(Not) coincidentally, this is what F# already does, with one project for language discussions (https://github.com/fsharp/fslang-suggestions) and a separate one for the language design (https://github.com/fsharp/fslang-design). This setup has worked very well for F# and is something I think worth considering.

[eyalsk]

Thank you so much for listening. ❤️

I don't really have much to say but for me GitHub is the way to go and with time, I'm sure the GitHub team will make it even better.

GitHub is the right starting point, again, at least in my opinion. :)

p.s. @MadsTorgersen, @gafter, @DustinCampbell, @CyrusNajmabadi I have one question though and I brought it up before, sometimes, I post IDE suggestions here (Roslyn repo) can I still do it?

[miloush]

I agree with the GitHub choice. It also helps to ensure there is a push for improvement on their side. :)

[orthoxerox]

@MadsTorgersen, @gafter, @DustinCampbell, @CyrusNajmabadi will you migrate existing language design issues yourselves, or do you prefer that we open new issues for features we are interested in?

[jpierson]

I've tried Discourse before a few months back and found it confusing and unpolished but I'd be willing to give another try and would prefer it over mailing lists. I think the most straight forward solution would be to stick to GitHub issues.

[DavidArno]

@MadsTorgersen,

Firstly, like others, I wish to thank you for listening to us and our sometimes (mainly in my case, I suspect) antagonistic views on the mailing list decision, and for acting on that feedback.

Secondly, given the two points:

1. The majority of the community would like language proposals to stay on Github,
2. Github doesn't currently have the tools needed to make this work as well as it could for the team or for many in the community,

What's the best way for us all to petition Github for better tools? Would you like us to individually contact them? Is it something you would prefer to take on yourself? Is there a way we could collectively "sign" a request to be sent to them? Or do you have something else in mind?

[jnm2]

I wonder if Discourse could be made to crosslink to and from GitHub. GitHub would have to open an API for this and Discourse would need an extension written.

[DavidArno]

@jnm2,

Are you volunteering to write that extension? 😈

[DustinCampbell]

@eyalsk:

p.s. @MadsTorgersen, @gafter, @DustinCampbell, @CyrusNajmabadi I have one question though and I brought it up before, sometimes, I post IDE suggestions here (Roslyn repo) can I still do it?

Yes! This change is only to move C# and VB language design to a repo separate from Roslyn. The C#/VB compilers and IDEs will still live in the Roslyn repo. Nothing changes about that.

[AlgorithmsAreCool]

Thank you @MadsTorgersen !

Discourse is the way to go.

• Markdown
• Good email support
• Mobile friendly!!!
• Doesn't butcher code snippets like the mailing list
• Can login with GitHub account
• Potential to centralize discussion about DotNet in general (on GitHub we have to hop between dotnet*, Azure*, Microsoft*, aspnet* and others)
• Good search support
• Nice link embedding (for github issues?)

The only real downside is the increased difficulty of crosslinking issues, but i don't think that is a dealbreaker at all. GitHub issues are designed for bug tracking and code review, not suggestions and ideas. These issues with hundreds of comments spanning many months are hell to follow on here.

The move to put formal proposals in csharplang and vblang is also great. You should probably disable issues on there and only accept pull requests that have to under go review to make sure they are fully fleshed out.

[dsaf]

I don't like Discourse but here is an example of a mid-size community around a GitHub repo:

http://community.monogame.net
https://github.com/MonoGame/MonoGame

[craigajohnson]

+1 for keeping the Roslyn repo and the new language design repos in GitHub.

[xoofx]

👍 for using GitHub (A much welcome wise decision! Seeing mailing list was eventually in the balance I was 😱 ) and pushing for GitHub improvements regarding issues/discussions management!

[KirillOsenkov]

GitHub or Discourse please.

[AlgorithmsAreCool]

@xoofx My only concern about pushing GitHub for better discussion management is the timeline. How long should we wait for github to handle this problem for us?

[xoofx]

@AlgorithmsAreCool can't really tell about the timeline... but I don't think there is any real blocker that would make GitHub issues completely unusable... it is not ideal, but far better than other ecosystems not genuinely connected/integrated to the GitHub PR/issues workflow

Though, as @hishamhm suggested, I like also the idea of a separate rfc repo like rust/rfcs. In this repo, you have nothing else than a bunch of RFC documents rust/rfcs) and related PR and issues. When there is a PR there, it is just about design (e.g it doesn't trigger a rebuild of the rust/rustc repo for example). It is easier to track changes related to RFC, make diff between commits...etc.

[m0sa]

my vote (in order of preference): 4 3 2 1

[alrz]

I'd probably agree that GitHub issue tracker is not optimized for general discussions, hence the name. That was one of the reasons that led us to mailing lists in the first place.

On the other hand, I really liked the idea of a "Discussion" tab in GitHub as it would resolve all of our issues!

Waiting to hear from @Haacked on that. With that possibility, I think it'd be better to stick with GitHub.

[TonyValenti]

@MadsTorgersen -
Thank you, thank you, thank you!

My vote is GitHub, GitHub, GitHub, GitHub, and lastly, Discourse.

[CyrusNajmabadi]

I have one question though and I brought it up before, sometimes, I post IDE suggestions here (Roslyn repo) can I still do it?

Yup. The Roslyn repo will still be where the IDE is developed. Suggestions/PRs always welcome :)

[DustinCampbell]

My vote is GitHub, GitHub, GitHub, GitHub, and lastly, Discourse.

That's my vote as well @TonyValenti :smile:

[bondsbw]

GitHub should consider directly integrating Discourse.

One issue with GitHub issues is mobile. It lose some features (such as formatting toolbar, preview, and reactions) compared with desktop. Markdown is allowed but is a bit more involved, requiring backticks (for code) which are often tucked a couple of levels deep in mobile keyboards.

[alrz]

Both lack some features from each other, in that case GitHub seems like a safe bet since we are already here.

[MadsTorgersen]

@Haacked was on the Microsoft campus today on other business, and we had an opportunity to pass on our feedback. 😀

While he is not directly in charge of this, he asked me to gather up the proposals here and send them to him. To start with, I think @HaloFour's list of suggestions above is fantastic, and I'll also pass on @bondsbw's suggestion to integrate Discourse directly into GitHub.

Anything else?

[benaadams]

Not mailing list, not rosyln. Though github or discourse.

However, if github add (yet more) two more repos? Something in the vien of csharplanglabs and vblanglabs?

And maintain the separation of discussion of ideas and work on towards fully designed specs; that I think you were looking to achieve (as else the same swamping may happen to the design repos making is harder to identify issues with on going work vs new ideas and features)

[alrz]

Of all things that I like about Discourse among other things @HaloFour mentioned,

• Responsiveness
  
  
  
  • Updated threads should bump back to the top
  
  
  • Real-time and desktop notifications
  
  
  • Real-time Markdown preview
  
  
  • Search as you type
  
  
  • Async navigation
  
  
• "Continue where you left off" at comment-level (just like PR reviews that do this at commit-level).
• Overlay comment editor (you don't need to scroll to bottom, therefore not losing the context).
• Mobile view should not strip away edit and reactions (please!)
• Link tracking i.e. click count

[LordZoltan]

Having read through the various options, I have to say it's hard not to support Github as the place for this.

The proximity to the source itself is the killer: being able to hit a discussion, potentially contribute and then see it linked to a checkin is enough to nullify the deficiencies in Github itself as a place for discussion.

So the proposal as made gets my vote.

[jonstodle]

I think some people are too used to doing this stuff on Github: "if all you have is a hammer, every problem looks like a nail", etc...
I think using a proper discussion tool for the job is the right way to go; Discourse

[MgSam]

Thanks for listening to the community feedback. I'm very glad the mailing list decision has been changed.

I agree with continuing to use Github, though I share the concern that there certainly is still a lot of room for improvement in the functionality. Still, it seems the best of a bunch of imperfect options.

[vbcodec]

Large, complex and mass popular projects deserve for their own specific sites. Only such sites can provide great experience for users and owners. Create such site (for example dotnetlangs.org) and move there everything except code.
Github is wrong place for lang development (except compiler code), as it is lacking advanced features and result is mess. I don't know why you want stuck here more than is needed. In fact, it was artificial merge, as almost none proposal, discussion or posting bugs, reference single file of compiler code. I perceived such situation as temporary, until you create more sophisticated solution. Clearly, staying here, splitting repo for two languages and resorting on mailing lists as remedy for Github shortcomings, is directly opposite to what should be done.

[timgoodman]

I think either Discourse or Github would be fine, and both are preferable to email. But I'm a little unclear on why Discourse being a separate site is considered a significant downside.

At the risk of stating the obvious: Instead of linking from the homepage of the repo to a list of the issues tagged as "discussion", you could just link to the Discourse forum. We could keep Discourse open in one browser tab while exploring GitHub issues in the other tabs, and just copy the URL of an issue into Discourse when we want to link to it in the discussion.

Is there some extra functionality you get by keeping them in the same place, or is it just that people don't want to have to copy links between the two sites?

[gulshan]

I am all for Github. But just for your information, .net foundation does already have a Discourse forum-
http://forums.dotnetfoundation.org/

[eyalsk]

@jonstodle

I think some people are too used to doing this stuff on Github: "if all you have is a hammer, every problem looks like a nail", etc...

To me it looks like GitHub is a toolbox and currently it's missing few tools, nonetheless, a good toolbox to start with.

[jonstodle]

@eyalsk I'm fear of stretching this analogy too far: why wait for Github to include the tool, when it's already available. And we're not even if or when that'll happen.

[eyalsk]

@vbcodec

Github is wrong place for lang development (except compiler code), as it is lacking advanced features and result is mess.

I think you're exaggerating, many projects handling their discussions at GitHub and it works for them and it kinda works for us too here so please define mess.

I don't know why you want stuck here more than is needed. In fact, it was artificial merge, as almost none proposal, discussion or posting bugs, reference single file of compiler code.

I'll cite the GitHub team "Issues can act as more than just a place to report software bugs."

I perceived such situation as temporary, until you create more sophisticated solution. Clearly, staying here, splitting repo for two languages and resorting on mailing lists as remedy for Github shortcomings, is directly opposite to what should be done.

The reason they split the repo has nothing to do with GitHub _shortcomings_, they do it anyway because they want to have more control over proposals and a repo for each language make sense as both are completely orthogonal, in fact they are also orthogonal to Roslyn and separating them is the right thing to do.

[eyalsk]

@jonstodle

@eyalsk I'm fear of stretching this analogy too far: why wait for Github to include the tool, when it's already available. And we're not even if or when that'll happen.

I wouldn't mind using either but I fear that the moment we will move to Discourse the opposite will happen, meaning, we will miss features from GitHub.

Proposals have their own development cycle, they are versioned too like any other content and so if discussing source code in issues make sense I fail to see why discussing another kind of content doesn't make sense and if it works for many other projects then why this is special?

Now, I understand that GitHub is missing few features, I really hope they will add them soon but I still think it's great, maybe it's just my _bias_. :)

[ViIvanov]

I'm for keeping discussions on GitHub.
The main benefits for me is simple, easy and native linking between discussion, issues and code and cozy editor for Markdown.

I have used a "flat discussions" a lot of years and found it not confusing me.
Having discussions separately from issues sounds good, hope GitHub team will hear it.

[scottdorman]

At least on the C# repo, it looks like as new proposals are added a corresponding issue is also created to "champion" that proposal. (See https://github.com/dotnet/csharplang/issues/52 and https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md as an example.)

Would that mean if I had comments/questions about the proposal, I'd enter them as comments on the "Champion xyz" issue or create new issues?

In addition to the list of @HaloFour's proposed items, I'd like to add some:

• The ability to enter an issue directly against another file in the repo (be it markdown or code). I'd love to see this taken all the way down to a line level, i.e., be able to enter an issue against a specific line in the file (and have it versioned properly as well.)
• Relate files to each other. (A good example for this would be source code files showing examples, extended proposed syntax, etc. This allows more flexibility than keeping it in the proposal file as markdown code blocks while still keeping them associated with each other.)

[vbcodec]

I wonder if any improvements make sense at all. Throughout 2016 there was posted many proposals and suggestions, how to shape VB 15 and CS 7. How much of it was implemented in languages ? Probably none. And even 'better', they implemented what was strongly discouraged by github 'community'. They are listening to their big partners to determine what and when implement, and tiny enthusiastic github community is only nice to hear, as it is not representative.

[NickCraver]

@vbcodec That's just wholly inaccurate, all of the new language features were proposed, refined, dropped, or postponed in the open on GitHub. Alternative facts have no place here, and add nothing productive to any conversation.

[benaadams]

@vbcodec I think I'll be using every one of C# 7.0 and VB 15 features

https://github.com/dotnet/roslyn/blob/master/docs/Language%20Feature%20Status.md

[scottdorman]

@vbcodec I have to agree with @NickCraver on that. The language teams do a great job of listening to feedback from the community. Language features have been publicly proposed and discussed since at least 2013 (starting on CodePlex). Have there been features that were dropped (for various reasons) that were highly desired or features that weren't so highly desired that ended up being implemented? Sure, but that's also to be expected.

Have there been missteps along the way? Sure, but that's also to be expected. If you're referring to the project/build system changes (csproj -> json -> csproj), those decisions aren't part of the language teams responsibility.

[HaloFour]

Indeed. There might have been disagreement on the implementation details but many of the features were proposed here or codeplex or uservoice. As I mentioned in one of the other threads, there is just an avalanche of proposals. Most of them are relatively small and most of them would provide some minor benefit, but few are really that impacting. A big question for post C# 7.0 might be how that backlog can be handled as the C# team certainly doesn't have the bandwidth to hammer them all out and implement them.

[scottdorman]

To add to my earlier comment (https://github.com/dotnet/roslyn/issues/17054#issuecomment-278941593), would using Projects make sense here?

[scottdorman]

Yea, some of the proposals have/had relatively minor benefit and some that were minor were required in order to implement something larger...and that's not always something that's clearly visible. I doubt there has been a proposal (except maybe some _really_ trivial ones) where there hasn't been some disagreement on the implementation details.

There are a lot of proposals overall and figuring out how to handle that backlog will be important.

[Joe4evr]

Would that mean if I had comments/questions about the proposal, I'd enter them as comments on the "Champion xyz" issue or create new issues?

I would very much like to know this as well. If staying on GitHub is chosen, I would hope that the "Champion" topics become the place to discuss/ask about that proposal. If moving to Discourse is chosen, then having a link to a Discourse discussion topic in the "Champion" issue should be added (similar to issues created on aspnet/Announcements that link to the issue where the announcement can be discussed).

[dsaf]

@MadsTorgersen

Anything else?

This might be off-topic but it would be nice to be able to save _draft_ Issues without making them public. Sometimes it takes more than few minutes to write something up well. This is one of few email advantages, not sure if Discourse has this.

[vbcodec]

@NickCraver

all of the new language features were proposed

Sure, Team usually post what they are implementing

@scottdorman

The language teams do a great job of listening to feedback from the community

Sure, They even have to do it. Every new issue must be readed anyway, to determine which labels apply to it.

If we define community as team + others, then we have great success and can proudly state that 'development of net languages are entirely driven by community'. But this is joke.
There is clear difference between proposals posted by team and by others. Team's proposals are implemented or postponed to later implementation. Other proposals are just labeled, mostly non commented (with few exceptions) by team, and wait to be GC-ed (first time while moving from codeplex to github, and now by moving to new repos).
All new features of VB15/CS7 was originated by team. Exception may be tuples, where I have posted proposal here http://roslyn.codeplex.com/discussions/542995, and also found that it was posted much earlier on uservoice https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/2083753-return-multiple-values-from-functions-effortlessly. But somewhere team member said that they had it in their backlog waiting for implementation. So it is not quite clear, where tuples originated.
Thankfully team also implemented null propagation operator and string interpolation, but only because there was thousands votes on uservoice. Current github community do not have that advantage.

Current order of precedence to implement feature is:

• team proposal
• overwhelming community demand (uservoice or big partners / communities)
• ingenious proposals from individuals (github or other sources)

Proposals that do not meet these criteria, are used to make 'friendly open source environment', statistically used for MS needs.

[DavidArno]

@dsaf,

That's what your markdown editor is for. 😉

Even VS Code now has live preview of md files as you type (though it didn't work properly for me for some reason). It's an approach that works well for me at least.

[dsaf]

@DavidArno how does this help if I want to write something up across several days across different machines? I don't want to save it outside of GitHub and I want to keep it close to where it will be published (Issues/Discussions tab).

[scottdorman]

@dsaf Wouldn't you be doing this in your own fork of the repository to then submit it as a PR once you've finished writing it?

[NickCraver]

@vbcodec You're arguing a paradox here. They originated from the team because those things existed before the GitHub repo did. They were ready to go. So they posted them in a well laid out fashion to kick up the discussion for the current release. Almost all of the proposals in GitHub were started somewhere else, very few language ideas are brand new. Saying that they weren't posted on GitHub to be implemented when it didn't exist just doesn't make any sense. The team started here with the most popular and useful proposals, so to argue they got implemented because the team proposed them isn't justified logic. Correlation is not causation.

In the past, number 2 on your list (overwhelming community demand) cycles back into number 1 (team proposal). GitHub was started with a new release on the horizon, so you're finding fault that community demand turn into full proposals. That's just backwards - we want that to happen. Often the team gathers many facets of the idea and aggregates them in a coherent way, also taking into account the widespread impact of interaction with various other areas on the language any new feature may have. This is no different from a PM coordinating a project. It's the language team's job to act as a guide and coordinate things here. That piece is working well.

[eyalsk]

@dsaf

This might be off-topic but it would be nice to be able to save draft Issues without making them public. Sometimes it takes more than few minutes to write something up well. This is one of few email advantages, not sure if Discourse has this.

Can't people use VSCode or similar to write it? and then post it when they feel it's ready? :)

@DavidArno You beat me to it, didn't see your reply. :)

@dsaf You can always use https://gist.github.com/

[DavidArno]

@NickCraver,

Whilst @vbcodec is, in my view, exaggerating when he claims nothing proposed by the community made it into C# 7, calling what he says "alternative facts" isn't helpful. I too share his concerns as to whether the proposal discussion mechanism changes will make any difference. The team have a poor record when it comes to acting on community feedback here:

Local Functions: started out life as a proposal for implicitly typed lambdas, but the team morphed this into local functions. I haven't yet found a use for local functions, since private static ones work just as well and we still don't have implicitly typed lambdas without using wrapper functions.

Type switch: started out as a pattern matching proposal, but only a tiny fraction of the proposal was implemented for C# 7. In theory, the rest will appear in a later version of the language, but this must be balanced against Mads appearing on .NET Rocks not so long ago claiming 80% of pattern matching has been implemented. So we may never get "proper" pattern matching expressions like match for example.

Out var: scope leakage was vehemently opposed by the majority of the active members of the community here. And the leakage of unusable variables from x is T y expressions was (as far as I can remember) universally condemned here. The team chose not to act on that feedback though.

However, the team are acting on our feedback over how proposals should be discussed, so things may be changing for the better. Obviously time will tell, and I really look forward to my concerns being proven ill-founded, but I remain concerned none the less.

[dsaf]

@scottdorman maybe I am just not a confident GitHub user but my preference would be 'New issue -> Save as draft -> Submit new issue' rather than what you are suggesting. However I might be wrong.

@eyalsk would you like a version of Outlook where you cannot save drafts? In the end of the day Word is a much more capable editor. I am just desperately trying to keep up with the modern cloud-based world. Based on this view I am not sure why users are even still required to download VSCode - it's just a packaged bunch of HTML and JS scripts + user's config. Is it a temporary workaround for slow internet connections? I don't know...

[AlgorithmsAreCool]

I think this thread is sliding off topic.

[Unknown6656]

I would love it, if the language design was moved to the new GitHub repos -- It would be clean and I would still participate (I absolutely _hate_ mailing-lists and I would stop contributing, if it would be the new communication platform).
My vote would be:

1. GitHub
2. GitHub
3. GitHub
4. GitHub
5. Smoke signals or some African rain dance
6. Discord
   ∞. Mailing lists

[timgoodman]

@Unknown6656 Archivability is an issue for smoke signals. I keep hoping someone will implement some sort of carbon capture to address this, but it seems to be stuck on the backlog.

[MadsTorgersen]

All, I've gathered up your ideas for improvements to GitHub's discussion support (those were great!), and sent them off to @Haacked at GitHub. I hope we can gradually see some improvements.

[eyalsk]

@DavidArno

Type switch: started out as a pattern matching proposal, but only a tiny fraction of the proposal was implemented for C# 7. In theory, the rest will appear in a later version of the language, but this must be balanced against Mads appearing on .NET Rocks not so long ago claiming 80% of pattern matching has been implemented. So we may never get "proper" pattern matching expressions like match for example.

To be fair _iirc_ he didn't say that 80% of the features were implemented I think he talked about scenarios and not too sure about the following but he was mostly speaking about C# 7.0 and 7.X, he also mentioned the match expression and he said that they are likely to add it.

Obviously time will tell, and I really look forward to my concerns being proven ill-founded, but I remain concerned none the less.

I don't want to derail the discussion and I'm really sorry but I feel it's important so here is the thing, I think that it's fine for people to criticise them for their decisions and disagree with them but in my opinion, _distrust_ doesn't have a place here because I think that once a person reaches this point then it's useless for him/her to be here.

[jnm2]

@eyalsk

but in my opinion, distrust doesn't have a place here because I think that once a person reaches this point then it's useless for him/her to be here.

Well said.

[aholmes]

I feel GitHub is a poor choice for this specifically because of it's flat discussion model. It's difficult to even follow what folks are stating in this thread because it's just a long list of replies. I've seen how important threads are for other discussions and mailing lists (FreeBSD, Linux kernel, PHP, etc). I envisage GitHub will fall on its face for discussing the design of C#.

I vote for Discourse.

[TonyValenti]

Perhaps we should put together a proposal for github outlining the
challenges we have with the current system. This may be a way to achieve
the best of both worlds without bringing on an additional platform.

On Fri, Feb 10, 2017 at 4:12 PM Aaron Holmes [e-mail]
wrote:

I feel GitHub is a poor choice for this specifically because of it's flat
discussion model. It's difficult to even follow what folks are stating in
this thread because it's just a long list of replies. I've seen how
important threads are for other discussions and mailing lists (FreeBSD,
Linux kernel, PHP, etc). I envisage GitHub will fall on its face for
discussing the design of C#.

I vote for Discourse.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/roslyn/issues/17054#issuecomment-279080654,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AM-qVjvQkZFC5a2F2ty4A7RcGCBs7K5wks5rbODggaJpZM4L7oAg
.

>

Tony Valenti

[timgoodman]

I think that it's fine for people to criticise them for their decisions and disagree with them but in my opinion, distrust doesn't have a place here

Agreed. I thought it was a bit disheartening that the initial reaction to the email list plan was not just "I really hate this plan" (which was a fine response) but also a fair bit of "Clearly they don't care about our opinions and are trying to silence us." It should now be clear that that wasn't true in this case, which is worth considering next time it seems like they aren't listening. Also, keep in mind that the move to developing C# and VB in the open is a huge change from how this team had worked for many years. When there are missteps, surely "old habits die hard" is at least as plausible an explanation as assuming some ill-intent.

[svick]

@aholmes

I envisage GitHub will fall on its face for discussing the design of C#.

There's nothing to envisage, GitHub has been used for that purposed for quite a while now. Even though the process is moving and changing, it's still GitHub issues. So I think you should be able to look at the old discussions to decide for yourself if GitHub is good enough for this.

[eyalsk]

@aholmes

I feel GitHub is a poor choice for this specifically because of it's flat discussion model. It's difficult to even follow what folks are stating in this thread because it's just a long list of replies.

So you hate flat discussions and yet vote for Discourse? _I don't recall they have an option to change the view but I could be wrong._

[MarkusAmshove]

From what I've seen from Discourse I really like it and thinks it is the best platform for this. Especially the browsing and mobile experience is far superior to github (for this kind of discussion).

[MadsTorgersen]

As for where to do C# and VB language discussion in the future, we (the LDT) have been following the last couple of days' discussion here, and there have been a lot of great points made.

At the end of the day, there are two things that people seem to still fall in different camps on - the good news is that neither are terribly divisive issues; most people seem to be alright either way, even if they have preferences:

1. GitHub or Discourse: Most are happy with either. There are preferences both ways, and arguments both ways are good. _We'll stick with GitHub_, and do what we can to mitigate the downsides, and hopefully it will in fact get better over time.

2. Same or different repo: Both have advantages. _We'll stay in one repo_, (per language) so that discussions have better discoverability, and are collocated with the proposals, notes, etc. that they are about. This comes with a tax in the form of more diligent labelling, and we'll take that tax.

So: Discussion happens in the csharplang and vblang repos, as issues with a "Discussion" label. From this thread it seems that this will be ok for most people, and from the LDT side we're also comfortable with it.

I won't have time to implement the changes until Monday Feb 13. By then I'll circle back here one last time, inviting you all over to our new place(s)!

Thanks!

Mads

[jnm2]

That is perfect.

[scottdorman]

@MadsTorgersen

We'll stick with GitHub, and do what we can to mitigate the downsides, and hopefully it will in fact get better over time.

Specifically regarding the downsides, I know you've collected a lot of the feedback (essentially regarding having Discussions in GitHub that are different than/separate from Issues) and passed it along to @Haacked, so this might be more of a question for him. Do you know if there is a public location (like a GitHub repo for GitHub) where this is being tracked (as an issue) that we can follow and/or add additional comments?

Discussion happens in the csharplang and vblang repos, as issues with a "Discussion" label. From this thread it seems that this will be ok for most people, and from the LDT side we're also comfortable with it.

There have already been a few proposals that @gafter and I have started talking about, but it was done in the context of the "Champion xyz" issue for the proposal. Should we table the discussion there and pick it up in a new issue? Also, should there be any sort of name/title convention for these discussion issues? (@Haacked, I think this is where having the ability to relate issues to one another, besides just referencing it, would be nice.)

Would it make more sense that the proposals are GitHub projects instead? So each proposal is a project, which would (as far as I can tell) effectively give the proposal it's own "embedded" issues area?

[chrisaut]

I like the "project" idea. For those who haven't come across them before on GitHub, here's one from TypeScript: https://github.com/Microsoft/TypeScript/projects/4

[hughbe]

Good to hear. I'd add another feature to my GitHub bucket list - some way to move an issue across a repo. The number of times dotnet/corefx gets an issue that should be in dotnet/roslyn is high!

Here's hoping GitHub will focus on the features you mentioned - time better spent than making the navigation bar black!

[alrz]

Along with cross-repo issue export, it could be an option to convert an "issue" to "discussion" when we have proper support for discussions. :D

[DavidArno]

@eyalsk,

I think that it's fine for people to criticise them for their decisions and disagree with them but in my opinion, distrust doesn't have a place here because I think that once a person reaches this point then it's useless for him/her to be here.

I fully understand your position and confess that I find your, and @jnm2's, boundless optimism a pleasant balance to my own cynicism. And the way in which the team have accepted the community's wishes here is cause for hope. I remain sceptical though: that's just the way I am 😊

[jnm2]

boundless optimism

Hehehe... it's more specific than that. It actually has a name. Hanlon's Razor. I don't see it as optimism- I had no idea if the team would in fact do what y'all thought was the right thing, or whether we were right- I see it as making an effort to understand what the situation looks like from the opposite point of view.

[HaloFour]

@MadsTorgersen

I'm ecstatic about the reversal. I'm a little surprised that you guys are sticking with Github, but I do think that it's great to have everything on one platform. That meeting with @Haacked must have gone really well. Hopefully Github can evolve to meet our needs.

[vbcodec]

@HaloFour
That's called 'developing in the open', democracy wins :)
But for lang development @gafter and @MadsTorgersen will post their proposals, and any community objections will be corrected by @CyrusNajmabadi . That's well established pattern :)

[eyalsk]

@vbcodec What's your point? :)

[HaloFour]

@vbcodec

There's a big difference between "open" and "democratic". It's never been implied that the evolution of the C# language would be a democracy. We get to watch the process, make suggestions and voice our opinions, but it's still the language team which makes the final call. I don't have a problem with this. I might disagree with some of their decisions and prioritization, and I certainly make my view known, but I have very little expectation that the team will reverse their decisions based on it. Of course I'm certainly thrilled when the voice of the community helps to influence the design team in their decision making processes.

[vbcodec]

@eyalsk
Just replied to @HaloFour 'little surprised that you guys are sticking with Github', that decision was made by community and not @MadsTorgersen himself. If fact he realized that he rushed with his decision, before asking community for their preference, and with this post gave us that chance.

As for lang development team have all rights for their dictatorship (thankfully transparent), in the end they take all responsibility in front of their management and users of languages.
Thing become less clear when they post design notes / proposals aimed for discussion (as I think), and then reject result of these discussion with 'thanks for feedback, but we will stay with original plans and won't change anything'. Surely current model of interaction team<>community is flawed, and leads to friction and misunderstandings.

[dsaf]

Actually it looks exactly like a democracy with all it's advantages and disadvantages. It's just most people are "voting" outside of GitHub.

[scottdorman]

@MadsTorgersen While you're gathering feedback to send to @Haacked, one thing that's extremely annoying is that sorting issues isn't persistent. (This goes to the ability to always keep issues that have been updated floating to the top of the list by sorting them "Recently updated".) Every time I browse to the Issues page of a repo, I have to change the sort option. That's a major pain. I want to be able to set it once and have it remember that setting. (I'd love for it to be a global setting, so I only need to set it once and it applies to any repo I browse, but I'd settle for it just remembering for each repo.)

[alrz]

You could bookmark the page with predefined filters. But I agree it'd be nice if "Discussions" tab sort by activity by default as it bumps up new/updated threads to the top.

[scottdorman]

@alrz Yes, but then I have a ton of bookmarks for each of the repositories, it only applies to those repos I've bookmarked and I have to remember to use the bookmark each time. It would be better for GitHub to simply remember my last sort choice and always use that.

[scottdorman]

Having it remember my setting would be even more useful on mobile where there is no option to sort. (As would autocomplete for @ mentions and a markdown preview.) Hey @Haacked, you're tracking all these requests and getting it to right people, right? (The GitHub backlog isn't public, so we can't track this ourselves.)

[eyalsk]

@vbcodec I'm sorry that you feel this way but the majority of people voted for GitHub and I'm pretty sure that the design team did their research too and concluded that GitHub is the right platform for them.

I think that changes and conclusions need to be based on reason but from what I can grasp you expect them to do it just because the community said so but this can't really work like that.

[vbcodec]

@eyalsk

expect them to do it just because the community said

Mainly, yes. While community isn't language designers nor compiler writers, most peoples participating here are experienced programmers, and they care about general experience provided by language. In case when most Giyhub community vote against changes, then team should hold on, and ask larger community to vote on these changes. But I don't think this is happen.

Staying on Github is probably discouraging most of these millions of VB/C# programmers, as they probably think 'meh, this is probably about compiler construction, don't care about it'. This way community is very small.

[eyalsk]

@vbcodec

Mainly, yes. While community isn't language designers nor compiler writers, most peoples participating here are experienced programmers, and they care about general experience provided by language.

More importantly we aren't the designers of C#, we are privileged to contribute, we are privileged to take part in this journey with them.

I honestly believe that they appreciate us for being here and I think that they take our feedback seriously but at the end they have to make decisions and we can't expect them to lean towards the community just because they like us, I mean this is not how you make rational decisions.

In case when most Giyhub community vote against changes, then team should hold on, and ask larger community to vote on these changes.

No, they have schedules, it doesn't and can't work like this, at the end of the day, Microsoft is a company and they have a business to run.

Staying on Github is probably discouraging most of these millions of VB/C# programmers, as they probably think 'meh, this is probably about compiler construction, don't care about it'. This way community is very small.

Why are you making these assumptions?

For many and I mean most programmers "writing code" is just a mean to an end, nothing more. (ask the IT guys... j/k 😆) and there's this tiny fraction that really love the science behind it.

Some people just like to read stuff and don't post anything but they are still here and finally what makes you think that moving to Discourse will make more people participate? I really doubt it. :)

[scottdorman]

At the end of the day, we aren't the ones responsible for the actual language design and aren't answerable to Microsoft for it.

By making the language spec available on GitHub, the team has opened it up for more direct and public discussion as well as the ability for the community to offer corrections and improvements as necessary. By also making the language design process visible outside of the language design team, we get to participate in that process by offering opinions and suggestions in a public forum.

The team has never been under any obligation to do either of these actions (making the spec and the language design process openly accessible) nor have they been under any obligation to "do as we say" and implement features that the community asks for (or not implement those we say we don't want). This community isn't the only group of people (customers from Microsoft's point of view) who use the language, need features, etc.

Who are we to say a feature should or shouldn't be implemented without knowing the full rationale behind why it was requested, how much technical effort it will take, what other features may be dependent upon it (or that it depends upon), and what the timeline should be?

I think the community that's here on GitHub (either coming from the Roslyn repo or new to the language specific ones) will be vocal and, ultimately, won't care where that discussion takes place, because we're the ones who are passionate about what features get in to the language, what they look like, and what other features we might want that the design team hasn't thought about yet.

I can say from participating in design meetings and discussions, that the team does appreciate our feedback on features and does respond to it and can be influenced by it. That being said, there's a lot more to it than just listening to what we have to say about a feature and that they are the ones, ultimately, who are responsible for the design of language. We get to participate, to a degree, in that process, which is more than some other languages allow.

No matter what decision is the final one (GitHub, Discourse, mailing list, etc.), some people will be happy with it and others won't. No decision is going to make everyone happy with the outcome. The team made a decision (use a mailing list) and then realized (because of overwhelming feedback) that it might not have been the right one and are responding to that feedback by considering other options. All of the feedback here has been taken in to account, options weighed and measured, and a more informed decision has been made. Not everyone is going to agree with that choice (and @MadsTorgersen even said as much) but it's the one that the team feels makes the most sense.

[MadsTorgersen]

Alright, folks. I've updated the READMEs, labels etc. over in dotnet/csharplang to reflect the use of issues there for discussion.

Any further discussion on how this works, _let's have it over there!_ 😃

I haven't touched dotnet/vblang yet. Let's run for a couple of days in C# and get the kinks worked out. But then _we'd appreciate any help we can get_ in rolling this out on the VB side.

Thanks again! See you on the other side! _So long, and thanks for all the fish!_

Mads

[svick]

@MadsTorgersen Shouldn't the Roslyn README also link to csharplang and vblang?

[MadsTorgersen]

@svick Great idea, do you feel like contributing a sentence or two there? 😀