Proposal: Move C# and VB language design discussions to their new GitHub repos #17054
Comments
|
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. |
|
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 |
Some projects have separate repos for language design discussion/proposals. Rust and Haskell are examples: |
|
@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. |
|
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. |
|
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. |
|
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. |
The very thought puts tears in my eyes! 😄 |
|
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"). |
|
To be fair, I don't think there's going to be a lot of fixing bugs in other repos from this one. 😄 |
|
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:
|
|
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
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031655.html |
|
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. |
|
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:
(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. |
|
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? |
|
I agree with the GitHub choice. It also helps to ensure there is a push for improvement on their side. :) |
|
@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? |
|
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. |
|
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:
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? |
|
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. |
|
Are you volunteering to write that extension? 😈 |
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. |
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. |
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. |
|
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). |
|
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:
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 |
|
That is perfect. |
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?
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? |
|
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 |
|
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! |
|
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 |
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 😊 |
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. |
|
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. |
|
@HaloFour |
|
@vbcodec What's your point? :) |
|
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. |
|
@eyalsk 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. |
|
Actually it looks exactly like a democracy with all it's advantages and disadvantages. It's just most people are "voting" outside of GitHub. |
|
@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.) |
|
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. |
|
@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. |
|
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.) |
|
@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. |
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. |
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.
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.
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. :) |
|
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. |
|
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 |
|
@MadsTorgersen Shouldn't the Roslyn README also link to csharplang and vblang? |
|
@svick Great idea, do you feel like contributing a sentence or two there? 😀 |
and others
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:
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. 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:
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
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
The text was updated successfully, but these errors were encountered: