MadsTorgersen commented 7 years ago

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:

We didn't consult the community before making the change
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:

Continue with Mailman
Use another mailing list
Use a Discourse site
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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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:

MadsTorgersen commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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:

Discussions tab
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.
Better mailing list support
1. Each repository automatically creates a set of email addresses to which new issues or discussions can be posted
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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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:

One for discussion new features or features under development
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.

iam3yal commented 7 years ago

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 commented 7 years ago

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

orthoxerox commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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:

The majority of the community would like language proposals to stay on Github,
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 commented 7 years ago

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 commented 7 years ago

@jnm2,

Are you volunteering to write that extension? 😈

DustinCampbell commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

xoofx commented 7 years ago

👍 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 commented 7 years ago

GitHub or Discourse please.

AlgorithmsAreCool commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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

alrz commented 7 years ago

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 commented 7 years ago

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

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

CyrusNajmabadi commented 7 years ago

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 commented 7 years ago

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

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

bondsbw commented 7 years ago

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 commented 7 years ago

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

MadsTorgersen commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

iam3yal commented 7 years ago

@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 commented 7 years ago

@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.

iam3yal commented 7 years ago

@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.

iam3yal commented 7 years ago

@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. :)

dotnet / roslyn