Language Design Process Moving (again) #16905
Comments
|
This has come up before. I kind of like things being in one place but the issues in this repo has become difficult to navigate. The blog post isn't resolving for me at the moment. What exactly are the mailing lists for? Would proposals/comments go there vs. the Github repo? |
|
What exactly are the mailing lists good for? Why couldn't we just use issues on those repos? I don't understand the philosophy behind mailing lists but just that it would drown the discussion in the darkness. |
|
@HaloFour I believe that's the intention, yes. I have a number of feelings about this, some of which I already shared on the blog post but will repeat here for completeness.
I've asked this before but I still don't have an answer- who is in charge of the language team? Is there even anyone at Microsoft that can answer this question? This team is literally run like a bunch of college kids working on a hobby project in their spare time. There is absolutely zero accountability for anything. |
|
Mailing lists are an absolutely abysmal idea for language suggestions. That decision will single-handedly murder community participation in language design outside of arguing over the vetted design notes. New ideas will die in the oubliette, drowned out in the noise. I simply can't fathom such a decision. |
|
I like the new repo. A ton. GitHub does not allow filtering notifications based on tags, so my options have been 1) miss out on design notes or 2) drink from a firehose. I concur with the others from personal experience that mailing lists == pain and will exclude all but the most dedicated (for one reason or another). |
|
@HaloFour Maybe that's the idea? @gafter and @CyrusNajmabadi are the only ones that seem interested in engaging with the community. |
|
@jnm2 That's a great point but if you don't use generalized notifications at all (I do not), it makes it literally impossible to follow what's happening across the MS ecosystem when its split into tons of repos. |
|
@MgSam I'm really not sure how organizing into separate repos makes it any harder to follow. This goes cross-repo, for example: https://github.com/issues?utf8=%E2%9C%93&q=label%3A%22Design+Notes%22+label%3ALanguage-C%23 |
|
I'd like to live in a world where people give things a try before coming to a conclusion on things :) If mailing lists don't work well, we'll change. But we should not be unwilling to try new things to see if they can help us out. Many of our colleagues (both at MS and at other institutions) use mailing lists for design, and find them a attractive and valuable solution. We'd like to try it out ourselves. -- It's worth noting, (to me at least), that a lot of language design used to happen through email. After all, that's what we had prior to trying out github-for-everything. We successfully shipped many versions of C# using this model. So i don't see any reason why, a-priori, an email system could not be an effective mechanism to tie into the design process. |
|
I like how Rust did this, they take proposals as PRs which have to follow a template. PR comments are used to discuss the completeness of the proposal itself (often from core team members), and there is always a "tracking issue" for community to discuss the feature. There is a mailing list but I think that is used for core team discussions in public. EDIT: Nope, it's been shut down 2 years ago. |
|
Not a fan of the mailing list, I agree with @HaloFour, using the repos for proposal in their respective language. So there if you're interested in a particular language and not the other, you can follow just that repo. If the feature is applicable to both, the proposal can be raised and link back to language repos. @MgSam Where's Lucian Wischik (@ljw1004) he seemed to also engage the community. It's a shame that the implementations can not also be split out from the Roslyn repo. So it is focused on the common aspects. |
|
It relies on them:
There have been cases where one or both of those things don't happen. Sometimes language decisions have been made in threads not tagged design notes. |
Mailing lists aren't new to any of us. We know how awful they are.
Not with the general public. So, who exactly is responsible for diving through all of the open language feature requests here on Github and posting them into the mailing list? |
|
@CyrusNajmabadi You can still reply to things on github via email. |
That's your opinion. It is, clearly, not universally shared. |
|
@CyrusNajmabadi Those successful releases were all before C# was open source, no? And the decision was made with zero community input. And I'd like to live in a world where decisions are discussed before they are made, not after. I understand as a Microsoftie there is an instinctive desire to imitate everything Apple does, but maybe that's not always the best decision? :) |
I have never seen that successfully work. Especially when you care about things like having a threaded conversation. |
Great question! Going to go get a crisp answer for that. |
Yes. But i don't see why being open source makes an email-list a non-viable system for communication. |
|
@AdamSpeight2008 You're right Lucian does sometimes engage, and Matt Warren does as well. Still, most of the team does not. Other members vary between complete indifference and outright hostility to the community. |
For the reasons people have listed- none of which you actually responded to. :)
I am extremely dubious that anything will be done, as when the move from CodePlex to Github happened there were also vague promises of migrating over the issues, none of which actually occurred. Even after all this time people are still reviving old issues that were orphaned in CodePlex. |
I responded by pointing out that we've had a very successful history using email as a communications medium. As such, the doom and gloom response to it aren't resonating with me. I acknowledge that we were successful with this system in an age when we weren't open source. But, as i mentioned already, i see nothing about being open-source that somehow makes email suddenly become non-viable. |
|
Isn't that a little disingenuous? When it was closed source, the group of participants was Microsoft-only, far smaller, and you all saw/communicated every single day with each other as a matter of course, no? So going from that to a system where dozens of people, mostly strangers, from around the world are entirely reliant on an email list to communicate seems like a big difference. |
|
@CyrusNajmabadi The Git and WiX mailing lists are finicky about plain vs html and have design flaws or actual bugs in the subscription and unsubscription processes. I shouldn't have to be subscribed to see stuff. I can't search it like I can with GitHub. Rather than using a smoothly designed mobile site, I'll have to work in my mobile email client and I'll have to continually work against the way the app was designed to work if for example you don't support HTML emails. I'll have to be careful with reply and reply all. I'll have to set up email filters and deal with space limits. I'll have to think about spam exclusions. So much headache and overhead. I won't have Markdown or syntax-highlighted code blocks. Google lists aren't as bad, but at the end of the day it feels like you're hacking email to fit a purpose which is better served by a more idiomatic medium. And you can't argue that this is not unfriendly to outsiders. |
|
Or raise an issue with Github to implement a discussion section. |
|
@MgSam: Who's in charge of the "language team"? That's part of the problem we are addressing with this move. The Roslyn repo represents too many different decision processes.
Here's what I wrote in my response on the blog:
As for the mailing list, can you just please give it a chance? Discussions have been overwhelming and hard to follow on GitHub, as they easily run to hundreds of unthreaded responses. Let's try this other thing, and if things really don't work out, we'll just look at it again. The process can (continue to) evolve. |
|
@MadsTorgersen When you say "discussion" is that just the LDT Members or does that include the wider open community? |
|
If money is the issue, note that Discourse offers 50% off or even free plans for projects that are open source! ;-) In all seriousness though, taken straight from their FAQ, emphasis mine:
At any rate, the bottom line of this comment is as follows. I'm chipping in here as a very casual participant in discussions around language design, someone in read only mode. If there's a GitHub issue or a Discourse or a similar system with lots of modern helpful features (e.g. great formatting and unfurled links to issues) I will interact (read only, so you don't see me). If you move this type of discussion to a mailing list for sure you'll loose 90% of the read-only participants. |
|
Everyone, please don't assume malice when there are other perfectly serviceable explanations. The team had pain and did what they felt they had to do. Like they said, they misjudged the impact on the community. |
|
Why didn't they talk to anyone about this before jumping the gun? Why is a blog post telling us what's already happened the first any of us are hearing about this? I mean the whole thing is surprisingly inconsiderate if it's not malicious. (edit: I'm upset but I wasn't meaning to imply that it's ACTUALLY malicious, it's just how it feels) |
|
@jnm2 I can relate but it doesn't make a lot of sense to me that something that clearly would have an impact on the community hasn't been brought to discussion! |
|
@eyalsk I like what you had to say. |
|
@jnm2 I mean I'm all for going back to old ways if they can just talk to people before jumping to a decision. They clearly need some kind of person whose role it is to manage community interaction, because this is going to damage forward momentum for C# contribution with some mild convenience for the creators. |
|
It was nice to check GitHub every morning to catch up on language discussions. It was really cool to see development happening out in the open like that. It's too bad that can no longer be a part of my morning routine. Not a huge loss to anyone, obviously, but it makes C# a much less exciting language to follow. |
|
I'm not anywhere near as active as folks like @NickCraver and @benaadams, but I saw this pop up on Twitter and I had to chime in. I come here about once a week to get a general outlay of what issues are being pressed or worked on. A mailing list is literally the least user friendly and community embracing technology that could have been picked. There are a ton of threaded bulletin board systems, some of which are amazingly good, of which Discourse is one. I would urge the team to walk this decision back. There's just no way I'm signing up for an email list. |
|
@jaredpar I shared your feedback with the search team. Thanks!
@DavidArno Yes, we are aware of them, but the additional feedback (and emailing support@github.com with specific suggestions) is always welcome. It helps us understand more scenarios, the degree of pain, and angles we hadn't considered. As to the specifics of this discussion, I don't participate much in the language design discussions, but I've enjoyed following along and reading them from time to time. The original post in the issue mentioned having design notes posted in another repository. I'd love to still see issues (or a PR) opened when a discussion is started with a simple link to where the discussion is happening rather than only posting the notes at the very end. So even if the discussion isn't happening here, I can follow along by watching the right repository. |
|
Hey all, First of all, for those that joined late or didn't read through the whole thing, let me repeat that I am really sorry for pulling this without warning. I was rushing it for the purpose of putting the right links in a blog post that we knew was going to be read far and wide, and that was a big mistake. There's plenty of constructive feedback above, and I wish we had had that discussion before I made the move. Sorry again! Secondly, thanks for your passion and investment in the community! The reaction against the mailing lists is overwhelming. I've been having a good time over there myself, but I do see some of the downsides that people have been pointing out, and many of which we (the design team) were sort of resigned to going in, as a tradeoff from GitHub's downsides. Some of the issues raised are with the particular mailing list management tool, some with using mailing lists in general. We will definitely take another look at this in light of the discussion above, and the suggestions in #16916. To the perceptions of malice, I am really sorry if it comes across as us trying to get away from community contributions. The purpose of the whole move was actually the direct opposite, that we were looking for a way to give discussion its own space, where it is easy to follow and participate. Clearly, a lot of you feel that we missed the mark on that. If you have experience - positive or negative - with options, I'd very much appreciate if you could share them over in #16916. We'll use that to help us rethink this. Thanks again! Mads |
|
Sorry to throw up such a stink about it, I was just scared for the direction of this and other related langs that I use and love. Thanks so much for your contributions, and responding. |
|
Hey @haacked ! Thanks for reaching out. I've emailed you an example of the types of problems we're running into. Thanks! |
|
Thank you for the consideration. I'd have to think that such a tool exists that would make everyone happy, even if your preference is to work entirely out of your email client. I have to ask, what email client are you using? I'm using both gmail's web interface as well as Outlook 2016 with gmail via IMAP. |
|
@MadsTorgersen The main issue I see is that you are going to lose valuable contributors, because they will not store their email / password in a system that stores it in cleartext, as @NickCraver said previously. |
|
Wow, when you compare the issues between 3 'large' dotnet repos you can see the problem! Roslyn has more issues, but more significantly, it has more issues with a large amount of comments! List to the search result for 'Most commented issues' (open & closed) I guess language design is more subjective and/or controversial!! No wonder the people who are looking at the issues as part of their day job want/need another system! |
|
Most of the most commented issues represent epics; long-lived, multifaceted and constantly evolving. It's no surprise that many of them became unwieldy. I don't think it matters what system you use if you try to manage your work items in such a manner it would become a problem. If the mailing list had even a fraction of the users as we have here I could probably trigger a similar cascade of useless* replies by bringing up something general and wide-reaching. Something that can track issues in a hierarchy to allow for breaking down a proposal into individually designable and actionable parts might help there. * "Useless" is the wrong word here. "Difficult to follow" and "continually obsolete" probably better captures my intention. Sorry, four month sleep regression and I'm barely functioning on coffee fumes. |
|
Just one thing, you tagged the wrong Matt Warren, unfortunately I'm not the one on the Roslyn team 😃 |
|
@mattwarren, @mattwar: You guys should totally duel. |
|
Well I'd settle for a chance to say hello, a duel seems a bit extreme!! @DustinCampbell I still remember the time you gave me commit rights to the entire OmniSharp org, good job I was honest and let you know!! |
|
We'll take your PRs anytime. :smile; |
|
I think it's worth reflecting on a few specific details. We all - in this community - understand that you have a language to design, language services and compilers to implement, testing, quality assurance, localization, deadlines, all this. Really: we understand. We are happy to leave you to it, and we do not want to be in the way of this. When you go out and say that C# is now open source, and Roslyn is open source, and .NET Core and ASP.NET Core and that this is a new era of transparency and that cross-platform inclusiveness is a priority and removing barriers everywhere is a priority, people who have been wanting to participate for a long time will be wanting to participate, to do what they can. They are chomping at the bits to contribute. Just now, the saga of dragging ASP.NET Core to all-the-way-through-cooked is finally closing, with the new MSBuild version of the tooling. ASP.NET Core went from item to item of confusion, back-tracking and befuddlement because of surprises. It's not so much that people are being mad about the cheese being moved, it's that we see it as being moved behind our back while we are putatively being consulted as experts in Cheese Location Fitness Optimization and Cheese Site Selection. Microsoft is a big company. A lot of you are working there together every day. You develop a shared culture, you can look each other in the eyes and send messages on a higher bandwidth. You can have meetings and hash things out. The community is still an outer layer on this onion. If C# being run with the community was what it was about, the idea would have been naturally: Publish that post, by all means. But end it by saying: "We are reconsidering the use of GitHub Issues for language feature design, discussion and coordination and are asking the community to help us select the solution that will work best." Invite us into the conversation. You have a community. It is a strength. See it as a strength. Make use of it. Make use of us. Trust us. See us as on the same team. Microsoft used email before NT was even a glimmer in Cutler's eye. It's not a surprise that Microsoft employees using a Microsoft email client tuned for the Microsoft way of doing things inside a Microsoft organization thriving on it will see email as a good thing. These are not accusations of brainwashing, just observations of emergent behavior. Not everyone will have the same email client (threading works ridiculously differently in different clients), be used to work being conducted in email, have an email address that is effectively usable for this purpose and so on. Maybe email will be the best (or "least worst") solution in the end... but don't by omission disregard us. We understand deadlines and pressure and shipping, and we would never stand in the way of doing those things. But if you say you want a community, along with that decision comes nurturing the relationship with it. Not just Microsoft asking us to trust you, also the community asking you to trust us. When that process stumbles, or when it looks like we're being kept out of the loop on something deliberately, or that decisions are made over our heads about things that affect us, this is the reaction you get, every time. Open source done well, having a community done well is massively, largely, overwhelmingly upside. It is a bit more work, but it's so much more productivity and collaboration and fun. If community isn't this, please take a step back and ask yourselves why. I should end by noting that I notice that you are trying. These things don't happen for lack of effort, just because it is incredibly hard for any organization to make this change. Microsoft has a strong culture and a large number of people. I mention ASP.NET Core because I've been seeing similar things happening there too for the past few years. I can't speak for everyone, but I personally appreciate everything that is being done as part of this enormous change. I have deep respect for so many people in this thread and it has surely been a big change on the everyday life of a developer at Microsoft. No one is expecting perfection and immediate harmonization. What I hope everyone participating has, no matter who they work for, is the ability to listen. Maybe a change to something else was unavoidable. But let us be part of the investigation. Saying "we have to stop feature work on C# 6 now or we can't ship it" can be traced to a business goal and a deadline. This can't. This is about how we communicate, and "this was debated" is not an argument unless it includes all of us. It affects us. Let us debate it too. Let our voices be heard and our opinions considered. If, after all that, you end up choosing typing every post in EBCDIC-encoded XML over Finger, I'm sure that as long as we can see the same things you saw in favor of that decision, we will all have an easier time adjusting and accepting it. |
|
I feel that those Issue / PR with large amounts of replies / comments are valuable collective resource. We (Roslyn) then get views from different angles and perspectives. we are not all elite programmers. That is really important to not to forget that, and let see the world from the different vantage point. Personally I see it from the point of a learner / amateur to the language, so can sometime spot things that could trip them up. Hence what (I perceive the from the experts as minor annoyance) when I ask for explanations and definitions. I don't have an educational qualification in the field of Computer Science or its related fields, eg a Degree or Doctorate. Being honest with you, I just barely got through my secondary education qualifications. |
|
What the heck is “mailing list”? Is it something from FIDO epoch, or kind of? C'mon, it's 21st century out here. |
|
@terrajobst .NET Core is Open Source
|
|
The C# and VB design teams have a recommendation for where and how to conduct language design discussion: #17054. Please comment there by Friday Feb 10! Thanks, Mads |
|
We are now taking language feature discussion in other repositories:
Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https://github.com/dotnet/csharplang/issues, and there is a draft spec at https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https://github.com/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https://github.com/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952. In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead. Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you. If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue. Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to #18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo. |
and others
The language team has decided to (again) move the language design process. Mads mentions this offhand in his recent blog post about the language direction.
C# language discussions will now happen on a mailing list and design notes will be posted in a new repo.
VB language discussions will also happen on a mailing list and design notes will be posted in a new repo.
As, to my knowledge, the community was not given any opportunity to voice input on this, I'm opening this issue so that those of us that have participated in language discussions are aware of the change and can provide any feedback on the process.
The text was updated successfully, but these errors were encountered: