Roslyn: What, no design notes?

[DavidArno]

Hello @MadsTorgersen et al.

There have been no design notes from the dev team since May; over two months ago. Aside from Mads appearing on .NET Rocks and disingenuously claiming that in C# 7, pattern matching will be 80% done (the real figure will be nearer 8% than 80), there haven't been any announcements on progress and plans.

Any chance of an update soon?

Thanks.

[MgSam]

While .NET, TypeScript, and other MS projects have become fully open source projects with major community contributions, my impression is increasingly that the Roslyn project is becoming much more of a source dump than an open source project. After some initial excitement when the code was first open-sourced on CodePlex, there seems to be little interest from the team outside of @gafter (and occasionally @mattwar, @ljw1004, @CyrusNajmabadi) in interacting with the community. Mads pops up literally only to occasionally post design notes and then disappears back into the ether.

Compare this to the repos for any of the other MS projects, where the principles regularly engage with each other and the community on Github.

This really is a shame, as I think the community can have a lot of valuable insights and contribute meaningfully (not counting myself in this, as there are lots of folks much smarter than myself who hang around here).

I'm starting to wonder if C# and Roslyn are being de-prioritized at MS. It's either that or it's being severely mismanaged. It's telling that a full 50% of features of C# 7.0 are championed by one person. Despite the stated goal of releasing more frequently, the pace of progress is still glacial compared to many other modern language being actively developed (C++, Swift, Rust, TypeScript, the list goes on and on).

It will have taken two full versions of the language, or at least 5 years, to add binary literals and digit separators, the simplest of simple features, from when they were first proposed. TypeScript has had 5 versions released in the last year. They will have designed, implemented, and shipped non-nullable types all while the C# team has punted this feature into a future version that is probably years away.

And that's not even mentioning that when they do meet, the LDM seems to choose at random what features they're going to talk about- the last design notes were on extension members which isn't even being considered for C# 7. This when there are many outstanding design issues for features that are on the table. Talk about putting the cart before the horse.

This project is desperately in need of some effective leadership and organizing, and for the sake of C#, I hope it happens.

[roterdam]

@MgSam You can't compare C# to TypeScript. One is a transpiler system and toolchain (sure mirroring ES6) and the other is a language used for more (without sounding too offputing) traditional software development.

You know what I hate. Tuples and Pattern Matching. I find them totally repulsive. Guess what? C# 7 will move at a pace that also accommodates and caters to a crowd that can be more conservative than you.

I love C# because it has a set of designers that are patient, thoughtful and decisive about the features they want.

It's not entirely a bad thing.

C++17 hasn't added much, C++14 didn't go too crazy either. Sure C++11 was a big jump, and it's been 5 years for that too.

I'm terrified at some of the "pro performance" proposals being made, by the same lot of people. Game developers are coming to C# and they want Unsafe APIs, allocating reference types not on the GC heap, MSIL inside methods, etc.

Then there is the pro F# gang. I open a .fs file and I go bananas, I don't understand anything. And now it seems there will be more of it in C# and it'll make me less productive. Nobody in the community thinks of that, but I'm so glad people steering C# as a language do think like that.

I will one day have to read C# code one of you may have written and I'm concerned I will not be able to understand much of it, because it'll be F# like "->" code all allocated on the non-GC heap with intertwined MSIL doing .tail prefixes and localloc's all over the place.

/end rant. There is another side of the story, that is being somewhat conservative to bring everyone along for the ride. I humbly request people who watch issue to see that side too.

[CyrusNajmabadi]

What would you like to know about? :)

And that's not even mentioning that when they do meet, the LDM seems to choose at random what features they're going to talk about

Language design is hard. It's inappropriate to focus solely on the near future, without also taking a thoughtful eye toward where you want to be heading in the long term. We continuously discuss a wealth of topics to make sure we feel that we're on the right path and we're not making decisions in the short term that we'll regret later on.

he last design notes were on extension members

One of the reasons to discuss extensions members is because it affects our thinking on how we do things in the tuples/pattern matching/deconstruction space. For example, if we felt that extensions could be used for deconstruction _if_ they were tweaked slightly, then talkign about where we wanted them to go was sensible. Similarly, things like extension constructors or extension conversions becomes very important if as we consider how different types might convert to/from tuples.

Language features are not designed in a vacuum. We have to consider how they work with the entirety of the language so far, as well as how they may work with what we think may be coming in later. We want to make informed decisions, and that means thinking and talking about all these concerns continually.

[AlgorithmsAreCool]

@MgSam I don't think this is being fair. TypeScript is still brand new as a language, they don't have 15 years and untold millions of lines of legacy code to consider. On top of that, typescript is still 80% javascript. They more or less just need to parse, type check and then strip out their syntax additions.

Roslyn needs to do sophisticated checking, lowering and compiling into a completely different language target (IL) along with the very ambitious goal of providing a public compiler API that serves major clients with different needs such as aspnet and visual studio while still being accessible to simple analyzers.

That being said, i am a bit disappointed by the change in tone from codeplex where the discussions where richer and more two-way. This is probably due to the larger community here that depersonalizes the discussion as well as creates a flood of messages to the same limited number of respondents.

As to the design 'monopoly' by @gafter....i don't mind. C# 7.0's feature list looks GREAT right now to me. I want every feature (and non-nullables and records) as soon as i can get them.

What concerns me the most is the monotonically increasing open issue count in roslyn that would seem to indicate that the project is either under-resourced or mismanaged.

I hope that @MadsTorgersen can comment on this issue, but i think that his email box has 10,000 unread emails from github on it and this will be lost in the noise.

[CyrusNajmabadi]

What concerns me the most is the monotonically increasing open issue count

It should be noted that different people feel very differently about bugs and bug counts. I, for one, have no problem with bug counts going up. What i care about is quality, and that doesn't have a direct correlation to bug count or trending direction.

[CyrusNajmabadi]

That being said, i am a bit disappointed by the change in tone from codeplex where the discussions where richer and more two-way

Feel free to ask continue asking questions. People will converse, as before, when time permits. :)

[AlgorithmsAreCool]

@CyrusNajmabadi

What i care about is quality, and that doesn't have a direct correlation to bug count or trending direction.

You are of course correct, but I think that an ocean of open issues makes things difficult to track effectively.

Edit:
It is not so much that the work isn't getting done as it is issues get fixed or obsoleted and never get cleaned up.

[HaloFour]

@CyrusNajmabadi

What would you like to know about?

There was an LDM last week on 7/13. Decisions came out of it which are changing syntax that had already been discussed here. I'd like to see the notes that came out of that meeting, perhaps with some bits of the discussion that led to the change. The team used to be quite good at writing up these notes and offering them here.

I think @AlgorithmsAreCool is right, maybe the team needs some kind of emissary who's role is to help coordinate the communication. Even if that were more one-way and resulted in better dissemination of the team communication to the rest of the community I think that would be a huge win over the situation today.

[eyalsk]

@roterdam You can't compare TypeScript and C# when it comes to technologies because they are doing two different things but you can certainly compare their development process! one is more transparent and open and the other just pretends to be open, the C# team shares the news with us when it's already too late to make any changes.

That's how I feel, maybe I'm completely wrong but that's just the feeling I have.

[ghord]

I think a lot of this is caused by looming 2.0 milestone. I'm sure roslyn guys are focusing on bugfixes and design work will pick up once next version ships.

[AlgorithmsAreCool]

@ghord I was feeling the same way before RTM shipped. The team can't stay heads down forever.

[vbcodec]

The reason that there is no new design notes or low level of conversation, may be that there is lack of developers who want to read and participate on this site. The fact is that there is small group 10-20 enthusiasts who daily track every news and changes. Others are visiting this site only to post bugs, or simple high-level ideas.
This is some disappointment, because there are millions of C#/VB developerr, and 'Future of C#' was fourth most viewed session on Build 2016, with 300k viewers
https://channel9.msdn.com/Events/Build/2016?sort=viewed&direction=asc#tab_sortBy_viewed

[AdamSpeight2008]

I'd be happy with an update once a quarter.

[DavidArno]

@vbcodec,

There are nearly 3,000 open issues here, a great many of which are related to new feature proposals etc. I think you are wrong in claiming that there's a lack of developers who want to participate. However, having posted their ideas, they are normally to be told (by a community member) that that feature has already been proposed in another issue. They read that, see that the comments are normally only from other community members, give up and leave.

The only way that Mads' team will see more people getting involved is by them being more involved themselves. MS claim C# is now "developed in the open". This is clearly untrue. We have a public source dump here, but the language is still developed behind closed doors. C# is failing as an open source project, because it's not developed in the open. Until the team start holding language design discussions in the open (or at the very least, publishing minutes of all internal discussions), there is no incentive for the community to get involved.

@ghord,
According to the last update to the plans for C# 7 (three months ago!), three of the features proposed are still in "feature specification" stage. That doesn't sound like an imminent release to me. If a release is imminent, then Mads really needs to buck his ideas up and get better at updating such status pages!

[HaloFour]

@vbcodec

The reason that there is no new design notes or low level of conversation, may be that there is lack of developers who want to read and participate on this site.

I agree, this is disappointing. However, I would argue that being less transparent will not likely attract a larger audience.

I don't know what the team could do in general to improve this situation. Certainly more exposure through the usual channels like Channel 9, MSDN Magazine, local events, etc. But I also don't know what the level of interest for a project like this really is, or the breakdown between people who view the repo and browse the issues v. people who actively participate to any real degree. I would expect that the real language enthusiasts would probably be a small minority.

@DavidArno

Until the team start holding language design discussions in the open (or at the very least, publishing minutes of all internal discussions), there is no incentive for the community to get involved.

This is what I would like to see. I would assume (and hope!) that minutes are taken of the LDMs anyway if only for the team to reference. It would be nice if that content were made available, even if in somewhat rough form. This would fit the bill of the role I had mentioned, an emissary between the team proper and the community. Someone on or close to the team who can sit in on these meetings and take these notes, clean them up somewhat for public consumption and then post them here.

[markrendle]

I'm starting to wonder if C# and Roslyn are being de-prioritized at MS.

Yeah, what with: the release of .NET Core with a cross-platform implementation of C# (written in C#) and an open-source editor to go with it; the acquisition of Xamarin with their tools for creating mobile applications using C#; continual talking-up of Unity3D in a way that strongly suggests an acquisition is in the offing there too; and the talk of AoT compilation of C# code to native stand-alone binaries for Windows, Linux and Mac via CoreRT... it really just feels like Microsoft's hearts aren't really in it anymore.

What I'm seeing is features that — to me, at least — seemed really quite simple and straightforward when they were first announced, turning out to be much more nuanced and complicated, and a team taking care to do it properly. It's far easier to iterate on newer languages like TypeScript, Swift and Rust because there aren't billions of lines of code out there to worry about breaking. And the infinite monkey cage that specifies C++ can (and do) do whatever they like because C++ developers _expect_ opening a project to be like walking naked into a forest of thorn-trees on a moonless night and diving headfirst down a deep, dark well that may or may not have a hungry honey-badger covered with angry bees at the bottom of it.

All that said, though, I'd like more updates too.

[CyrusNajmabadi]

What I'm seeing is features that — to me, at least — seemed really quite simple and straightforward when they were first announced, turning out to be much more nuanced and complicated, and a team taking care to do it properly.

This. Although i would augment it is: it's pretty much always known that any interesting feature will not be simple and straightforward. The initial 80% of the design can happen very quickly, but the rest takes ages.

Just tuples alone has garned hundreds (maybe thousands) of pieces of feedback internally and externally on how people want it to work. There are all sorts of ways we can take it and make it do more stuff (for example, should KeyValuePair/Tuple have any relation? If so, what sort?). We try to strike a balance between not taking on too much, but also not making a new language feature so isolated from the rest that it won't be enjoyable to use.

Then there's verification that we're not breaking anything (C# has a much higher bar around back compat than, say, TypeScript does). This is a large added tax to the process that does slow us down, but which our community has given long continuous feedback that they absolutely want this. And that's just the language side of it. On top of that, there's the implementation side. Remember that C# actually has to sit on top of an actual runtime with certain capabilities that we expose through the language. These have to actually be in sync and correct. This is not the case with languages like TypeScript. For example, in TypeScript, it's trivial to write 2-3 lines of code which produce no errors, and which contain nothing that subverts the typesystem (like a type assertion) that are considered typesafe by the compiler but which produce a type error at runtime. For example:

 var x: { a: number, b?: number };
 var y: { a: number };
 var z: { a: number, b?: string };

// much later

x = { a: 1, b: 1 };
y = x;
z = y;
z.b.charCodeAt(0)

The comparison to TypeScript is not appropriate as each language has different goals and different features it promised. TypeScript wants to statically identify constructs that _may_ be errors. But in doing so it might miss out on whole classes of issues (like above), or it may misidentify errors that will not actually happen. Because of this looseness, it's far easier to change the language and introduce new features as they have. That's a great boon to TypeScript, and i think it's the right choice for the domain it is going after. However, the same looseness does not apply to C#.

That's one of the reasons that certain features (like non-null) we consider much harder to supply. We strongly seek to make sure the feature descends through the entire language, without corners that leak bad behavior (either through false positives or negatives).

TypeScript also doesn't have to deal with things like metadata and how things are actually encoded and stored to be used by the .Net runtime. It is a 100% erased and only TypeScript source code is the source of information that TypeScript needs. The same is not true for .Net language likes C# which do not erase.

This has made even seemingly basic features (like Tuples) very richly complex. For example, because tuple names are represented in metadata as attributes, you can run into issues where when tuples are used in signatures that are inside the constraints of generic type parameters, then those names are lost. In TypeScript such an issue does not occur because they erase entirely and do not need to examine metadata to know what's happening. For C#/VB we have to, and this hole is something we need to plug because we know that if our customers hit this they will be both confused and upset. Without work here, the names they've put in their tuples would be lost, and they'd no longer get good tooling information about what these tuples actually represented.

This is just a _tiny_ slice of the broad depth and time that has to go into just a single feature :)

Now compound that with multiple features, which themselves overlap (i.e. Tuples and Patterns) and you'll find that language design takes a long time and that it's well worth it to spend that time so you don't end up releasing something you regret later but _can't change_.

Note: i do not want to make this into a discussion about TS vs C#/VB. I just wanted to provide insight to help understand why direct comparisons between them aren't seeing the whole picture. C#/VB could operate more like how TypeScript does (and there are times i wish we could!). But we have strong evidence that doing so would likely produce language versions that would deeply upset many of our user base.

[eyalsk]

@CyrusNajmabadi I fully agree with your posts, however, I think what some people want is not more features but more communication from the team.

[AdamSpeight2008]

Also the discussion tends to be more C# focused, which gives the impression that the VB language isn't being worked on also.

[CyrusNajmabadi]

AFAICT, right now, several team members that generally write up and notes are involved in an Ecma summit. :) I fully expect that once that is done that more recent notes will be forthcoming.

[CyrusNajmabadi]

which gives the impression that the VB language isn't being worked on also.

Which is another thing that makes comparisons to other languages not quite on point :) We've also got to work through all this stuff across multiple languages. And we have to consider how we're going to expose this through the Roslyn API as well (with all of its' back compat guarantees). And on top of all of that, we go and make things work in a multitude of editors :)

At the end of the day, we're not just creating a language and a black box that takes in code and spits out IL. We're creating a whole API for working with the language _and_ we're working on exposing all the APIs to allow you to work with it in an Editor context. It's a ton to do and we do the best we can at letting you see it by keeping the majority of our discussions and work happening here on Github.

My personal preference would be that we consider moving straight to github as the location where we write our minutes as the meeting is in progress. That might help with the delay between the meeting and the release. The downside is that it's very possible for things to be much more raw, unclear, and possibly even incorrect.

The current approach allows Mads the time to go through and dump a _ton_ of expository content into teh notes explaining the wealth of positions presented, the thought process we went through, the pros and cons of the different approaches, and where we finally landed (if we did land). This makes the notes much more understandable and helps avoid misunderstandings and immediate off the cuff reactions.

[eyalsk]

@CyrusNajmabadi I think we understand that you're doing ton of work and are aiming carefully so you won't miss anything in the process and get things wrong, I mean "better safe than sorry" right?

However, I doubt that people want you to exchange quality with communication, we're asking for _more_ communication on your side when it's possible and as often as possible!

The most frustrating things for us is hidden changes and decisions that are made without any discussions or involvement of the community, you're going through things and decide what's relevant and what's not and by the time it gets to the community it's too late! I know we have no say about actual decisions and that's how it should be but it also feels like our opinions are meaningless! and that is the actual problem, at least for me.

There's no transparency in the process, people don't know whether proposed features were even discussed because all the _important_ decisions and discussions are made internally

Now, it's pretty unreasonable to discuss every possible feature but features that are under discussions internally can be shared with the community, there are many smart people here, let them in!

People that propose features would also improve their future proposals if they could know what are the reasons for their proposals to be declined or approved.

It can also be nice if there was a clear roadmap for the language or at least blurry one that tells the community for say C# 7.x we're going to do that and in C# 8.0 we're going to explore this and that.

[CyrusNajmabadi]

but it also feels like our opinions are meaningless!

I'm sorry it feels that way. It certainly isn't the case, and much of our discussions are precisely because we've heard feedback from the community about what they think. I routinely go and read through the hundreds of back and forth comments we've had on numerous discussion to help inform my own opinion on the feature and what i think is best moving forward.

By the time it gets to the community it's too late

i don't think there's a single feature that has been that way for C# 7. :) Our designs and impls have already changed a lot based on feedback we've gotten from teh community. It's true at some point there will be final decisions and those may end up being the "that's that" point for those features. That's true of any language being developed. You eventually get to the point that you've heard all the feedback, you've discussed things to death, you understand the tradeoffs between the multiplicity of different options, and you feel like you're making the best choice for the future of the language and ecosystem.

Now, it may be that those decisions are not ones you want. Lord knows there are many decisions we make that _I_ personally don't prefer. But that's just part and parcel of the process :) As time goes on the process goes more from open ended questions and design spaces, to a more locked down path where it's a lot less around figuring out the direction, and instead ensuring that everything necessary is done based on that direction.

people don't know whether proposed features were even discussed because all the important decisions and discussions are made internally

Could you clarify this a bit? How would you prefer decisions be made? I think, currently, the opinion is that the LDM makes decisions. Decisions can take in feedback from people outside of it, but the decisions are ultimately in the hands of the LDM. As such, the process is inherently internal.

In other words, i'd love some clarification on what, _precisely_, is being asked for. Is it a faster cadence from LDMs to publications of the notes taken? Are there other asks from you guys as to what you'd want? I don't want to guess at things and i'd lke to know specifically so we can see what of those requests makes sense to us and what we can try to do better with.

Thanks!

[eyalsk]

@CyrusNajmabadi First of all, thank you for taking the time to discuss this with us.

Could you clarify this a bit? How would you prefer decisions be made? I think, currently, the opinion is that the LDM makes decisions. Decisions can take in feedback from people outside of it, but the decisions are ultimately in the hands of the LDM. As such, the process is inherently internal.

Okay, so currently say we have a feature that is discussed internally by the team, now, what I'm asking and I think that many people would agree with me is to post a summary of the internal discussions and this how I'd imagine the process should look like:

1. Internal discussion is taking place.
2. Notes are being written.
3. Notes are being refined for discussion.
4. Team member creates a new issue related to this feature!
5. Team member reference the issue to existing issue about it (if there is one).
6. The community discuss the feature.
7. Team members share their opinions in the open.
8. Team members have the final word and an explanation is given to the community about it.

It can also be nice if there was a document that summarizes the issues that are created at step 4 or even a tag for it like "Internal Discussion" so the community would know what's hot! and can follow it.

_Obviously, this is a rough idea of what I think it should look like._

Now, like @AlgorithmsAreCool said, maybe having a community manager for the language that will take some of the pressure off for refining the notes and posting them to the community can help tremendously.

You can probably ask the TypeScript team about their process and _maybe_ learn something from them even though the technologies are vastly different.

So yes, we would like to have LDM notes as early as possible and we would like to know what's going on when changes are made especially when it comes to changes that were never discussed by the community.

Currently, it _feels_ like the process is similar to this:

1. Internal discussion is taking place.
2. Notes are being written.
3. Notes are being refined for discussion.
4. Rinse and repeat until final decisions are made.
5. Team member creates a single note called Design Notes for many LDMs that took place.
6. Community "WHAT?"
7. Yes! it's final.

Seems like the waterfall model to me.

Hopefully this clarifies few things for you.

Everything I wrote is from my own observation of the current state if I generalized and you share a different point of view please share it with us. :)

[markrendle]

For me personally, as primarily a lurker of the dotnet repositories, I like seeing updates regularly, even if they are just "Nothing much happened this week" or "We've had a design meeting but Mads is at an Ecma summit so the notes will be published when he gets a minute." It's about not going dark.

On a similar note, remember that GitHub tells you when something was last updated, and, for example, Language Feature Status.md hasn't been updated for 2 months. As outsiders we can't tell whether that's because there's nothing new to report or nobody's got around to updating it. And yes, we are developers too, and yes, we, too, suck at documentation and communication, but we hold you guys to a higher standard because _you're Microsoft_. :neckbeard:

The idea of minuting meetings directly into a GitHub issue or doc or something sounds good at first blush, but then I remember how some of the communications have gone over the last couple of years of this New Open Microsoft Adventure, and the not-necessarily-best ways certain changes/deprecations were (accidentally) announced, and, well... if I were you, I'd probably be wary of publishing anything that hadn't been carefully constructed and edited and probably proof-read by a couple of people for good measure. Remember: Fear The Rage.

[vbcodec]

@CyrusNajmabadi
Thanks for your answers, but this is not what we want. How team work, is not our needs. We just want to know current state of Roslyn in terms

• state of implementation particular features - compilers, editors and other tools
• planned, changed, removed features - what, when and why
• decision being made by team
• active participation in discussions on language features and proposals

First two points are most important. We need design and implementation notes Design notes should be posted when team decide to design, change or implement feature (on prototype and final code), and are aimed mainly to gather feedback and discussions. Implementations notes should be posted regularly, just to track state of implementation features on booth prototype and final code..

Another problem is lack of any informations about VB. I am pretty fine that all proposals and discussions are made in context of C#, but I want to know what will be implemented in VB. Do you still maintain feature's parity between C# and VB ? Good news is that tuples will land in VB. But what with source generators, replace/original, typeswitch and other features ? None info about it. Recently I have found that team post progress on Twitter. For example here is news that Tuples work in VB
https://twitter.com/ThatVBGuy. But why no such post here ?

There is no official C#/VB site, with news, events, discussions, proposals and anything other related to C#/VB. Other languages have such official sites, and Microsoft should create such site for C#/VB, especially that they are expanding these languages to other tasks, communities and platforms. Twitter, github and MSDN Blogs combined, are poor dispersed and inefficient replacement for such site.

[AlgorithmsAreCool]

Well some good news is the DotNet Foundation has just brought in @rachelreese as Community Director.

This can only be a good change, but I still think we could use someone down in the github issue trenches to bridge the gap in communication. I think Rachel's role is much higher level than that.

[eyalsk]

@AlgorithmsAreCool That's awesome! :D

[CyrusNajmabadi]

Ok! So let's go through that list:

• Internal discussion is taking place.
• Notes are being written.
• Notes are being refined for discussion.

So these are already definitely happening. Refinement is taking longer here due to many important things going on. That's unfortunate, and i imagine we could do better here potentially by having other people help out.

• Team member creates a new issue related to this feature!
• Team member reference the issue to existing issue about it (if there is one).

I'm not quite certain i understand these ones. We already have github issues for our language proposal. For example: https://github.com/dotnet/roslyn/issues/206

Or do you just mean: in that issue just make a reference to the notes that happened? If so, that seems reasonable.

• The community discuss the feature.
• Team members share their opinions in the open.

Doesn't this already happen on the github issues and language design notes?

• Team members have the final word and an explanation is given to the community about it.

I feel that this is what the notes do when decisions are finally made. i.e. Mads is quite good about saying what we discussed, explaining all that was discussed, and then explaining what decision we finally settled on if we actually made a decision

Overall, it feels like this doesn't change much of hte process _except_ to make a stronger github link between design meeting outcomes and existing language feature proposal issues.

[eyalsk]

@CyrusNajmabadi

I'm not quite certain i understand these ones. We already have github issues for our language proposal. For example: #206

Or do you just mean: in that issue just make a reference to the notes that happened? If so, that seems reasonable.

Well, what I meant here is for _every_ LDM or as few as possible a team member would write notes and post them here, so the process would be something like this:

1. A feature is being discussed internally.
2. A team member is creating an issue about the recent discussion with the tag "Internal Discussion"
3. A team member reference old community issues related to it to the new issue he/she created.
4. The community discuss this feature.
5. Another meeting is taking place about this feature.
6. The community continue to discuss this feature.
7. Some decisions are made internally.
8. The internal discussion ends about this particular feature.
9. The team member closes the issue.

The point here is to get information out to the community as early as possible rather than waiting for the Design Notes that takes quite a bit of time, but for something like this to work I _think_ that you need some sort of a community manager.

Doesn't this already happen on the github issues and language design notes?

It does, to some extent but Design Notes takes a long time to get to the community and by the time it gets to us it _seems_ like it's already too late, like you already know what you're going to ship and we have no say about it so it's useless to discuss it.

Again, that's purely how I feel, maybe other people feel and observe different things.

The time LDMs are taking place and the time notes are getting to the community is important if this process is slow then it means you already made quite a bit of decisions or even assumptions and the community can discuss things but we will never have the chance to make a real difference.

Overall, it feels like this doesn't change much of hte process except to make a stronger github link between design meeting outcomes and existing language feature proposal issues.

Yes, this would be pretty good.

[MadsTorgersen]

Hey all, thanks for sharing your thoughts on the engagement of me and my colleagues – and sometimes lack thereof!

Personally I want to own up to the lack of design notes lately. It hasn’t been for lack of design _activity_ (you’ll be relieved/scared to hear)! On the contrary we’ve been frantically trying to get all the remaining details worked out in time to ship a compelling feature set that is right and beautiful and well thought out in every possible way as part of “VS 15”. With this amount of end-game pressure I have personally been skimping on notes, sharing rough drafts with team members who have full context, as opposed to what I would _like_ to do, which is write them out nicely with good explanations of alternatives and motivations, and share them broadly.

I _currently_ believe that we tackled the last major design issue for C# 7.0 this very morning. I can’t wait to tell you more about it, and the week after next I will.

Longer term, we need to think about whether the way we all engage can be better. Does it scale well, and facilitate the right discussions and feedback? So that’s something for us to focus on as C# 7.0 lands and we set ourselves up for the _next_ one. Having had the first full design cycle in the open, there’s a lot we can learn and get better at. I look forward to candid feedback on that, too, over the coming period of time.

[AdamSpeight2008]

There is no official C#/VB site, with news, events, discussions, proposals and anything other related to C#/VB. Other languages have such official sites, and Microsoft should create such site for C#/VB, especially that they are expanding these languages to other tasks, communities and platforms. Twitter, github and MSDN Blogs combined, are poor dispersed and inefficient replacement for such site.

I've always thought that the Roslyn repo should be broke apart into smaller repos:-
_Especially now roslyn is pulling in nuget packages, or maybe going in different directions._

• Core
  
  
  
  • LDM Notes
  
  
  • Code common to both languages.
  
  
  • Build Server stuff.
  
  
  • Jenkins.
  
  
• C#
  
  
  
  • Issues / Pull Request
  
  
  • Feature Development Tracker
  
  
  • Language Spec
  
  
  • Compiler
  
  
  • IDE
  
  
• VB
  
  
  
  • Issues / Pull Requests.
  
  
  • Feature Development Tracker
  
  
  • Language Spec
  
  
  • Compiler
  
  
  • IDE
  
  

As it focus the issues to a specific language, the team get more targeted notifications.
The repo isn't as big and monolithic, may be attracting more to contribute. Even tackle open issues and submit a fix / pull request.

[CyrusNajmabadi]

We already have two repos for our open/closed stuff, and it makes life _much_ more unpleasant. Splitting things more sounds like adding a ton more complexity for little (any?) gain.

I'm concerned about this bit as well:

may be attracting more to contribute

1. I'm not sure that that will be true.
2. If you want to contribute, it's now harder as coordinating something across all those repos will take significant effort.

Take, for example, a language change. You will have 3 separate repos to go through to get things done.

This is the problem with any split. It presumes that cutline is appropriate for everything that needs to be done. However, there are many other cuts that have now become much more difficult. For example, the IDE team (that i'm a member of) does not think of the IDE parts as being split over VB/C#. Indeed, we work on them as one unified layer. Needing to be jumping between three different repos for everything would be a very large tax.

[gafter]

@MadsTorgersen

I _currently_ believe that we tackled the last major design issue for C# 7.0 this very morning. I can’t wait to tell you more about it, and the week after next I will.

Sorry, I've already spilled the beans over at #12597

[AdamSpeight2008]

@gafter Can we have a LDM Label?

[gafter]

@AdamSpeight2008 We have a "Design Notes" label that will be applied when Mads writes it all up.

[AdamSpeight2008]

@gafter
If you've already spilled the beans over at #12597. I think it this type of "secret" LDM post that this issue is about.

[eyalsk]

@gafter Can't we have a label for you too? j/k :)

Again, The "Design Notes" label is great but sometimes team members would post stuff early and it would be great if we could have a label for this, this will allow us to engage early and filter issues more quickly.

The issue I have with "Design Notes" is that this stuff takes a long time for many reasons, I think that adding a label for more rapid stuff makes sense.

[svick]

@AdamSpeight2008 @CyrusNajmabadi

What I would like is to be able to receive notifications about language design issues, without also having to receive notifications about all PRs to Roslyn code. As far as I know, splitting the repository is the only way to achieve that. But that may be an issue specific only to me.

On the other hand, the confusion between fsharp/fsharp and Microsoft/visualfsharp or, even worse, between dotnet/home, dotnet/core, dotnet/cli, dotnet/corefx and dotnet/coreclr makes for a good argument against splitting.

[AdamSpeight2008]

@svick
They could be sub-repos.

dotnet/roslyn/cs/
dotnet/roslyn/vb/

[HaloFour]

@svick You mean changes to the specs themselves? Could be achieved through opening and maintaining an issue per spec. When the spec changes they can bump the issue. Would be nice if github would have email subscriptions to folders or files within a branch or repo, though.

[eyalsk]

@svick I don't know what's confusing about it but then maybe people that aren't following the development of the .NET stack are less familiar with it and so confusion is kinda inevitable.

@HaloFour Yeah, in addition it was nice if GitHub had pinned issues as well as comments.

[ghord]

FSharp has separate repository for language design process. I think something like this would be nice.

[eyalsk]

@ghord Yeah, only they use User Voice which personally I dislike, it feels like ideas goes into a limbo there, I like the fact that we have the privilege to post ideas/proposals and discussions on GitHub, it feels great.

[jmarolf]

Here are the problems I am hearing about on this thread.

Problem: _Design notes are published frequently enough._

I don’t have too much to add here. Mads is in charge to the language design process and I will gracefully defer to him in all matters concerning it.
That being said I personally like the idea of language design discussions happening on a separate repo so things are easier to keep track of. What are the other people’s feelings on this?

Problem: _Don’t have a clear picture of what the team’s priorities are or what we are working on._

We operate internally on a 3-week sprint cycle. We could just publish some notes updating people on what we accomplished in the past 3 weeks and what our priorities are for the next 3 weeks. Would people want to see this or would it be too much noise?

Problem: _I can’t find a centralized place that can give me the tl;dr version of what’s happening._

Perhaps we should have a landing page such as http://www.typescriptlang.org/ that gives people on overview of what is currently planned. We have been doing blog posts about new features but I don't think we have a grand central location for all this info.

I just wanted to say thanks to @DavidArno for starting this discussion. I am very glad that people are voicing concerns about our process and how we are designing and building Roslyn. The only way we can improve is if people continue to help us find the problems and we work together to find the best solutions. What are the other pain points I've missed that we can do something about?

[HaloFour]

@jmarolf

That being said I personally like the idea of language design discussions happening on a separate repo so things are easier to keep track of. What are the other people’s feelings on this?

I like the idea of everything being in one place. However, if that means that it's difficult to track changes to the language specs specifically then it might be worth separating them. Perhaps one repo dedicated to design specs and high level proposals vs. this repo which will track the tasks to implement those proposals and bugs?

Would people want to see this or would it be too much noise?

I have a feeling that this wouldn't be as useful as it might sound. People might watch it a bit too obsessively and complain when someone changes their focus from "foo" to "bar", or that they're not working on "baz".

Perhaps we should have a landing page such as http://www.typescriptlang.org/ that gives people on overview of what is currently planned. We have been doing blog posts about new features but I don't think we have a grand central location for all this info.

I think that this is a great idea. A landing page that offers an immediate high-level overview of what Roslyn is and offers (both language-wise and API-wise) might help drive more interest in the project in general.

It wouldn't hurt to also update the Wiki on this repo a bit. It's painfully out of date.

A high level chart of proposals would also be nice. Obviously there'd be a bar that would have to be reached in order to be added to the chart, but it could give an idea as to if/when specific proposals may be considered for implementation. To a lesser extent just a table of the proposals that are slated for v_next_ would be nice. On CodePlex we had this for C# 6.0 and VB14 which made it pretty easy to see what was on the immediate horizon. You have to dig through a huge mess of issues to find #2136 which isn't quite as easy and obvious to follow.

[jmarolf]

I have a feeling that this wouldn't be as useful as it might sound. People might watch it a bit too obsessively and complain when someone changes their focus from "foo" to "bar", or that they're not working on "baz".

Perhaps it would be better to simply highlight the accomplishments the team does each sprint? I would like to be as transparent as possible about what we are doing and why without burdening people with the day-to-day rigmarole of development. I would also, personally, like some focusing point so that we can say "feature x,y, and z were done this sprint, please try it out and tell us what you think."

It wouldn't hurt to also update the Wiki on this repo a bit. It's painfully out of date.

Good point. We should update it (I think there are some bugs on me about that 😨). But we should also make it so someone can just submit a PR to update it themselves.

[eyalsk]

@jmarolf

I don’t have too much to add here. Mads is in charge to the language design process and I will gracefully defer to him in all matters concerning it.
That being said I personally like the idea of language design discussions happening on a separate repo so things are easier to keep track of. What are the other people’s feelings on this?

I have a mixed feeling about this, in general I think that it's a good idea but I hope that people won't get too confused and wonder where to post things because some people aren't following this repo so closely as some of us.

We operate internally on a 3-week sprint cycle. We could just publish some notes updating people on what we accomplished in the past 3 weeks and what our priorities are for the next 3 weeks. Would people want to see this or would it be too much noise?

Personally, I'd love to know that but like @HaloFour wrote I feel like people would be too _religious_ about it and maybe it will even get them upset when features aren't prioritized as they want but I think that the best way here is to do a _pilot experiment_ and and see how people react to it and whether it's useful.

Perhaps we should have a landing page such as http://www.typescriptlang.org/ that gives people on overview of what is currently planned. We have been doing blog posts about new features but I don't think we have a grand central location for all this info.

Yes, please! almost all technologies have some sort of a website, however, I think that this website needs to be built in such a way that it targets different audiences and it's important to identify them and make sure the experience is great for everyone whether it's a C# developer, a VB.NET developer or someone that want to use Roslyn to develop tools.

There was also a post where the person asked what is the official definition of C# and I had to dig that from the MSDN somewhere so such a website will probably solve this, it's probably meaningless and trivial to us but for people that are new or just curious to know what C# stands for it _might_ be important.

Perhaps it would be better to simply highlight the accomplishments the team does each sprint? I would like to be as transparent as possible about what we are doing and why without burdening people with the day-to-day rigmarole of development. I would also, personally, like some focusing point so that we can say "feature x,y, and z were done this sprint, please try it out and tell us what you think."

The VSCode team have an iteration plan for the whole month and a central document for everything, it's pretty pleasant to see that.

Maybe you can get some ideas from them. :)

[jmarolf]

I have a mixed feeling about this, in general I think that it's a good idea but I hope that people won't get too confused and wonder where to post things because some people aren't following this repo so closely as some of us.

Talking to the F# folks, I think the key for success here would be diligence in kindly redirecting people to the language discussion repo. I assume we would always get issues filed in the "wrong" place sometimes, but I think it would be manageable to redirect. It happens today with clorclr and the like and I don't feel like its a burden, just part of managing issues.

do a pilot experiment and see how people react to it and whether it's useful.

Right, we can course correct how we communicate things over time. I think it might make sense to start out being more abstract and then adding detail as people ask questions.

make sure the experience is great for everyone whether it's a C# developer, a VB.NET developer or someone that want to use Roslyn to develop tools.

I agree with these categories I believe we have:

• C# enthusiasts that want to know what's next and maybe participate in the language design
• VB enthusiasts that want to know what's next and maybe participate in the language design
• Tool writers who want documentation and samples on how to write tools

The VSCode team have an iteration plan for the whole month and a central document for everything, it's pretty pleasant to see that.

Very cool, I like it.

[miloush]

I have no troubles spotting the LDM notes. It might be worth having a wiki page with links to all of them, but not sure how much benefit that would be compared to searching for the label - maybe just put this link to one of the pages instead.

Like @eyalsk, I would personally love to see the notes from 3-week, even if unpolished, but I agree with others that the reception might vary. Also once these notes would be produced, I would expect the demand or need for proper LDM notes to decrease. That said, I do share the feelings of @DavidArno, currently I don't have very clear idea of what is on the plan for VS15 and what not, although I believe I am following the repository relatively reasonably.

I am indifferent to the landing page. People are still making new and new pages, and that has its costs. I believe there is already enough opportunity for language enthusiasts to participate if they want to. I agree though that the tool writers and users of Roslyn have tough times finding documentation and samples. This kind of support was great at the beginning of the project but has now somewhat diminished.

And I agree with @svick that I am glad there is a single place for Roslyn and I would be cautious about splitting. I need to follow like 6 repositories of ASP.NET to have at least some idea of what's going on there and that's not exactly great. People are filing issues at repositories they are not supposed to, many updates are just "react to changes in other repository" and it's just.. not fun.

Roslyn is a repository with the highest traffic I am following at the moment and I have to say I am impressed with how well are you dealing with it.

[jmarolf]

It might be worth having a wiki page with links to all of them,

Good idea. Might improve discoverability. I think everyone has their own workflow for how they track progress on this repo, I don't think it would hurt to have another way.

I agree though that the tool writers and users of Roslyn have tough times finding documentation and samples. This kind of support was great at the beginning of the project but has now somewhat diminished.

I agree here. Unfortunately I don't know what sort of discussion we should have as a community. The way forward seems clear: we should publish more documentation and samples and ensure that those we publish are of high quality. I am to blame for some of that as I have not been giving samples the attention they deserve as of late. Again, not much I feel needs discussion, we should just do it.

I am glad there is a single place for Roslyn and I would be cautious about splitting. I need to follow like 6 repositories of ASP.NET to have at least some idea of what's going on there and that's not exactly great. People are filing issues at repositories they are not supposed to, many updates are just "react to changes in other repository" and it's just.. not fun.

I hear you loud and clear and I don't personally want separate repos for C#, VB, IDE, Debugger, etc. However, I think it would be great if all the language specs were in a separate repo as markdown files and as language discussion happened we would merge in changes to the specs. Does that also sound laborious?

[eyalsk]

@jmarolf

I hear you loud and clear and I don't personally want separate repos for C#, VB, IDE, Debugger, etc. However, I think it would be great if all the language specs were in a separate repo as markdown files and as language discussion happened we would merge in changes to the specs. Does that also sound laborious?

Sounds excellent to me, however, in my opinion it seems like there's a need for 4 repos.

1. This repo where implementation, discussions and stuff are taking place.
2. A repo for the language specs.
3. A repo for the Roslyn APIs.
4. A repo for the website.

I don't know but maybe 3 and 2 or 3 and 4 can share the same repo if it makes sense but Roslyn APIs aren't really documented, isn't? I know that there's this but it's not really up-to-date, right? so maybe it's time to do something about this too. :)

The ASP.NET team have a repo for their docs that the community can contribute to and help with it, can be a great idea to do the same here, I think, again, just my personal opinion. :)

What do you think?

[jmarolf]

@eyalsk I like this. It reads as 4 separate repos to me,

This repo where implementation, discussions and stuff are taking place.

I read that as read that as _this_ repository dotnet\roslyn.

A repo for the language specs.

Something we need to create like dotnet\roslyn-language-specification

A repo for the Roslyn APIs.

Perhaps this a version of our current wiki that people can contribute to like typescript, with the idea that we would greatly expand it over time. Or like @eyalsk suggests, we could have a separate docs repo like asp.net that would be hosted on a separate website. If we do go with a separate website what do we want to do with our wiki? Should we still keep it but have different information there? What does everyone think?

A repo for the website.

Presumably we would redirect roslyn.io here as well as some C# and VB specific urls. The repo being something like roslyn-website

[AdamSpeight2008]

I like the idea of a separate website (or git repo) for document and specification, but only for versions released.It then can be used for asking usage questions, rather than them getting intermingle with roslyn design and build questions.
The roslyn wiki should be for in flux features / api.

[ghord]

Separate repo for language design is excellent idea. Right now, newcomer has to dig through thousands(!) off issues, most of them unconnected to design process which I think is a major barrier.

It would also allow pulling all design markdown files from different branches in roslyn repo into one place.

[vbcodec]

@jmarolf
Do Mads must write design notes ? Other members also may post these design notes.

We do not need transcript of every discussions, that guide sprints. We need to known important events. Important means:

• team decided to implement new / dropped (in previous version) feature. These notes are aimed mainly for discussions and feedback. Team should actively participate in these discussions, as this is core of 'developing with community'
• team decided to drop feature. There should be some explanations why it was dropped, if / when it may return etc
• team changed feature and that change have impact on experience while using this feature. This impact may be performance, syntax, semantic, limitations (or new possibiliteies) and anything other. For exapmle instead updating #12597, there should be posted new desing notes.

Design notes will form sort of chronicle, which will be useful, for someone who want to track development of the languages.

Team may also post implementation notes,, just to inform us that some feature was implemented fully / partially in prototype / final branch. Someone may be interested to try some features, despite it may be not complete.

New site should be great for C#/VB, but not something like http://www.typescriptlang.org, which is few static pages with links and few examples. We need site that is real HQ of languages, something like http://dlang.org. Such site should contain design notes, discussions, examples, links, articles blogs, sharing experiences by team while designing language and by users while using languages and anything other important to these languages. Github should be reduced to code repository, basic informations and posting bugs.

[jmarolf]

@AdamSpeight2008

separate website .. only for versions released.
roslyn wiki should be for in flux features / api.

I don't get the distinction here. Couldn't we just have a separate branch of the documentation repo? Why do you feel documentation for in-development features is best served on the wiki? Are you thinking that this is more about implementation notes than documentation while features are in development?

@vbcodec

We do not need transcript of every discussions, that guide sprints. We need to known important events.

If I am interpreting you correctly, you want a summary of the decisions made after an LDM meeting posted shortly after the meeting concludes. Do you also want a detailed write-up of the thoughts that went into those decisions or do you just want the summary?

but not something like http://www.typescriptlang.org ... We need site that is real HQ of languages

I agree that we shouldn't just do _exactly_ what the typescript homepage does. We should put all the things there that the community and new users cares about. You list some examples later, but what do you feel are the best parts about http://dlang.org? What information would you personally find valuable?

Github should be reduced to code repository, basic informations and posting bugs.

Could you elaborate on why this would be better? It seems you are suggesting that we have our own forums etc. that do not interact with the GitHub community at all. Is there something about GitHub that is lacking? How specifically does the D languages approach play out in practice for people that want to be a part of language discussions?

[AdamSpeight2008]

@jmarolf
Lets say Pattern-Matching is released to public via an official release, eg VS15
but some parts of proposal didn't make it, say recursive patterns.

Doc Repo
   \ Pattern Matching

Roslyn Wiki
  \ Recursive Patterns

There is nothing stopping use put a link from documentation repo to the "Experimental" features of the Roslyn wiki. The distinction is that the wiki is subject to change, the doc repo is Tenant: Compat.

[jmarolf]

@AdamSpeight2008 But wouldn't we just want Recursive Patterns to be in a vnext branch on the documentation repo?

I think we may want to constrain the wiki to just be about the in-and-outs of contributing to dotnet/roslyn while the documentation repo is about documentation of all the public apis that tool makers would use.

[eyalsk]

@jmarolf

If I am interpreting you correctly, you want a summary of the decisions made after an LDM meeting posted shortly after the meeting concludes. Do you also want a detailed write-up of the thoughts that went into those decisions or do you just want the summary?

Personally. I want to have the thoughts that went into these decisions, people can wait 3 weeks or an iteration before a summary is posted by Mads.

I agree that we shouldn't just do exactly what the typescript homepage does. We should put all the things there that the community and new users cares about. You list some examples later, but what do you feel are the best parts about http://dlang.org? What information would you personally find valuable?

I don't think that the TypeScript website is _bad_, I mean it's quite clear where things are and navigation is pretty simple, it supposed to be an informative website and that's how it was designed.

I kinda like the D front page but then when I go there I see this statement about the language and I really wonder how it will work in this imaginary website of ours that need to speak to different audiences and generally when you make a statement that has multiple faces it's never clear.

I really love the part where they give a brief explanation about D in the "Why D?" section as well as the middle section where they give a summary of "News, Learn, Community, Documentation, Contribute and Packages", it seems useful but it needs to be updated regularly to be really useful.

Now, to answer your question directly, I don't really know what _best_ or/and _useful_ means, I mean when a person comes to a website he/she probably ask themselves "Where do I need to go to accomplish this thing or things?" as opposed to "Where do I want to be?"

So if I'm going to build this imaginary website and this website should be the central place for people to get information I'd probably focus on 4 main things and prioritize them as follow:

1. Layout and Navigation

This is important for any website but even more so when the website needs to speak to different audiences.

1. Documentation

The documentation needs to be clear and approachable to all people on all levels, e.g., language references, language specifications, Roslyn APIs all of these things need to have a central place in the website.

1. Community

This page is going to answer questions like "Where do I ask questions about language X", "Where do I ask questions about Roslyn?", "Where do I post feedback?", "Where can I contact the community?", etc...

1. Tutorials

Resources and learning materials that are posted both by the team or by the community, whether it's blogs, videos, etc...

Github should be reduced to code repository, basic informations and posting bugs.

Just to voice my opinion about it, I strongly, heavily, totally disagree with this! GitHub is a great place for discussions, it's easy to label things and track things, it makes it easy for the team to see on going discussions and for people to mention other people or reference discussions, really I don't think we need to externalize this because it works pretty good, yes it can be improved but that's up to GitHub.

The point is to make things more transparent not more complex and a forum definitely brings complexity.

Could you elaborate on why this would be better? It seems you are suggesting that we have our own forums etc. that do not interact with the GitHub community at all. Is there something about GitHub that is lacking? How specifically does the D languages approach play out in practice for people that want to be a part of language discussions?

As far as I know the design discussions of D are taking place in their forums.

[vbcodec]

@jmarolf

If I am interpreting you correctly ...

Design notes may be short summary or long detailed descriptions. It all depends how much quantity important (see my previous post) decisions was made, that affect developers. If team announce to add new feature, then we need detailed description of this feature. On the other hand, if feature was changed, in some important way (to us), then we need to know what was changed and why, and do not want to know all team's thought and discussions that was lead to this change.

..but what do you feel are the best parts about http://dlang.org?

IMO, there are no best part. This site provide full spectrum informations for anybody who want help or participate in development

How specifically does the D languages approach play out

Their approach is to use single site for any discussions, and that site is http://dlang.org, not github. Look at their github repos (https://github.com/dlang), there are no issues on most repos. They have on site forum, that is used to discussions, while github is only for code dump. This approach is good, because there is single site for any engagement, which is confortable.

[miloush]

@vbcodec GitHub is pretty much the 'single site for any engagement' with Roslyn, isn't it?

[vbcodec]

@miloush
Not.
Github is very focused on code repos, and all available features are to manage these repos. It was not designed to provide exhaustive support for project's sites in general way.

[eyalsk]

@vbcodec

GitHub is the site for any kind of engagement with Roslyn! currently we have no other alternatives unless you consider UserVoice that I really despise and dislike with all my heart.

I think that GitHub is a great place for discussions, whether you like it or not it's your choice! people can decide for themselves whether GitHub fits their need or not and it doesn't even matter what it was designed for as long as it fits your needs, it's simple.

Their approach is to use single site for any discussions, and that site is http://dlang.org, not github. Look at their github repos (https://github.com/dlang), there are no issues on most repos. They have on site forum, that is used to discussions, while github is only for code dump. This approach is good, because there is single site for any engagement, which is confortable.

So they have zero issues and they are going to a completely different site to post these issues where you cannot use mention and you cannot reference anything and you consider this a good approach... sorry but this doesn't make sense to me at all!

[vbcodec]

@eyalsk
Now team must improve their engagement on github, by posting more design notes, clear some mess with issues and update obsolete non-code content. But github is not real HQ site, and labels are not real menus.

As for possible site, any forum's features may be added to provide great experience, the same or better than github,

[eyalsk]

@vbcodec What's good about menus? they are hierarchical, you can't filter them and nested menus aren't pleasant, labels are are used for navigation just like menus would, the only difference is menus are sorted (for you) and labels aren't, meaning, you have to use the search, personally I like the search.

Bottom line, I guess we will have to agree to disagree. :)

[ljw1004]

Swift does their language design over an email list. I read some interesting quotes...

That pipermail interface is barely an interface. I feel like the Swift guys are intentionally clinging to the mailing list as a method of weeding out contributors. If you want to participate, you have to put up with a pretty arcane communication system.

.

As a lurker curious about the language but not dedicated enough to read through a daily email log, I mostly get by with Erica Sadun's recaps.

.

I signed up for the mailing list and immediately regretted it. I am interested in helping, but this is miserable.

.

There's nothing arcane about using mailing lists for high volume discussion. They work extremely well for it and have for decades.

I personally manage a mailing list with ~20 posts per day. There's grumbling about email -- it's not archived, not easily searched, hard to keep track of the separate discussions. Some requested that we move over to github issues so it's easier to keep track of threads (with the idea that folks who prefer email can just rely on the github <-> email interface).

[AdamSpeight2008]

The design notes are important as some contributors may not have been part of the project since it inception, or have access to other microsoft resources.

[MgSam]

I've been taking a break from commenting after venting a little bit in that post in the top of the thread. Some thoughts on things people have suggested:

• More insight into what work is happening and why would definitely be appreciated. Also, involving the community in prioritization decisions would make more sense than what currently happens.
  
  
  
  • For instance, C# 7.0 is now confirmed to have dropped Source Generators. This makes the only "major" features, IMO, tuples and local functions. Both of these are pretty close to being syntax sugar and will not really enable new scenarios that weren't possible before. This means C# 6 and 7 will ultimately be syntax sugar releases. I would have gladly delayed every other C# 7 feature for Source Generators which many in the .NET ecosystem have been planning on in order to enable new functionality. Perhaps the larger community may have agreed or disagreed, but either way, they should have been given a vote.
  
  
• I don't think splitting into more repos makes anything easier. If tags are used effectively, it is quite easy to find the LDM notes. A link to a filtered view of the repo could also easily be put on the Github landing page.
• People got waaay too caught up in my comparison to TypeScript. TS is not the only language I compared to. For example, JavaScript and C++, 2 languages with code bases older and even larger than C#, are currently evolving much faster than C#. We have to stop sticking our heads in the sand here- C# is dropping in popularity, despite what Microsoft PR would have you believe. Every language popularity index has shown this.
  
  
  
  • I watched the video from Build this year where Mads proudly trumpeted C# being in the top 10 or something like that in popularity at Stack Overflow- a few years ago it was number one. The language needs to evolve or it will die- and the current (slow) pace of development just isn't cutting it. If this means the design team needs more team members or new leadership, then go out and hire them.
  
  

[vbcodec]

@MgSam
Fresh or simple language may evolve faster than mature. While features increases linearly, complexity increases exponentially, so cadences must be longer.

[HaloFour]

@MgSam

I agree with everything you say.

This makes the only "major" features, IMO, tuples and local functions.

And type-switch. To be fair there is a _lot_ of ground work being laid for pattern matching between type-switch, deconstruction and wildcards (7.1). I agree that source generators will be big and I think they will open a big sandbox in which potential new features can be explored without changing the language proper.

I don't think splitting into more repos makes anything easier.

I whole-heartedly agree. I think that good labels and a good/maintained wiki will solve nearly all of those problems. Plus a landing page for the language that can help users for different audiences explore the language and development process.

As for the popularity, I don't think that the language is the big problem there. It's the ecosystem. Until C# can run directly in the browser (or transpile to JavaScript), run natively on embedded devices with blazing-fast speed and run in Linux-based ecosystems I don't think C# can do a lot to compete with the top players. People aren't choosing to use Java, for example, because it has better language features.

That's not an excuse for the C# evolution to slow to a crawl. But it's important to solve the problems and not chase the fads.

[MgSam]

@vbcodec I doubt anyone would claim C++ is either "fresh" or "simple", yet that language is now evolving faster than C# as well.

@HaloFour I agree that platforms are part of the issue, but they're not the sole determinant. Xamarin is certainly a useful thing that people use, but when you're a team starting a new cross-platform project the case for using Xamarin gets harder and harder to make when C# is stagnating compared to the alternatives.

I think if no one higher-up at Microsoft admits there's a problem here it's not going to get fixed. The issues are a lot bigger than the frequency of Mads dropping off design notes. Anders doesn't lead C# development anymore. Who has taken his place? From my outsider perspective it appears to be no one. The language design process cannot succeed without effective leadership.

[AdamSpeight2008]

An example of why design notes are important, especially for offline discussions. Example

[CyrusNajmabadi]

Anders doesn't lead C# development anymore. Who has taken his place?

The design team leads together on this.

I think if no one higher-up at Microsoft admits there's a problem here it's not going to get fixed.

A lot more evidence needs to be presented to indicate there is actually a problem _to the level_ that you are indicating :)

So far, i've heard a bunch of good feedback generally related to the difficulty it is to keep track of what's going on in a project as large as roslyn with github as the medium. There has also been requests for different types of organizational structures around how we do things. It's clear to me things could be tweaked slightly to make things far nicer for a certain segment of users we have. However, that's a far cry from the intimation that there's a very large problem going on.

[CyrusNajmabadi]

People got waaay too caught up in my comparison to TypeScript.

It's not that "people got waaay too caught up in the comparison". The point in the responses was to show why such comparisons are not suitable as different languages have different goals and issues they have to consider which can dramatically impact things like language velocity.

You cannot simply compare one language to another without considering _deeply_ all the issues and concerns they have. There are pros and cons of the different sorts of approaches and release velocity is one factor among many.

[gafter]

I would have gladly delayed every other C# 7 feature for Source Generators

Dropping other features would not have helped. The difficulty with Source Generators is not the compiler - that part was fairly straightforward. The difficulty is getting all of the rest of the tooling working smoothly. There simply are not resources on the affected teams to get it all done in the C# 7 timeframe.

[jaredpar]

I would have gladly delayed every other C# 7 feature for Source Generators which many in the .NET ecosystem have been planning on in order to enable new functionality.

Expanding on what @gafter said here.

We actually invested considerable resources in source generators for this release. The compiler is the easy part and was done rather quickly. This is true even though the compiler work is actually two features: source generation and replace / overrides.

The challenge with source generators is not actually the language / compiler, it is instead the overall experience in the IDE. That includes semantic analysis, Intellisense, debugging, etc ...

From a compilation perspective source generators function a lot like analyzers. At a specific point in the compilation pipeline hand them a SyntaxTree, SyntaxNode, symbol, etc ... depending on how they registered. The output of the generator is a string which is immediately converted into a SyntaxTree and added to the pipeline. Some interesting items to consider with cycles + ordering but all very solvable.

From an IDE perspective though when to generate source is an enormous problem. This is essentially user code that can take an unbounded amount of time to complete. Yet the output of the generation is critical to the success of many IDE features.

Take Intellisense for example: Imagine if for example on generator is furiously spitting out extension members based on the code the user is currently typing. The only way Intellisense can be correct is if it considers the output of the generator based on the latest source code. That means functionally the generator must be run + completed on every key stroke before we display Intellisense.

That's a real problem. It essentially inserts 3rd party code directly into one of the most performance sensitive areas of the IDE. Doing so in this fashion is a recipe for bad performance and frustrated users.

An enormous amount of time in generators went to solving problems of this nature. A lot of progress was made here and we have worked out the basics of changes to the design that would make the feature significantly more palatable for a good development experience. But it does require a significant amount of work and it just doesn't fit into this release.

Perhaps the larger community may have agreed or disagreed, but either way, they should have been given a vote.

Voting wouldn't have helped here. The problem isn't that we didn't invest resources. Instead it's that the problem required more time than we had allotted for this release.

[vbcodec]

@MgSam
C++ is not evolving faster. Their cadence is 3 years, while C# is average 2 years. C++ 11 was largest update with just new lamdas, type inference, and few minor tweaks. C++ 14 was minor tweaks, and C++ 17 is fail where all planned major features were rejected. They have serious issues with major features like concepts (over two decades of trials), GC, reflection, modules, async and others that are multi year dreams with many failed attempts.
Java is not progressing at all, and other languages are irrelevant,
C# delivers solid features with every release, and roslyn alone can be viewed as important feature especially for design team and other tools makers. Maybe tuples and type switch are just sugar syntax, but they are very useful, and this is most important for developers. C++ developers said for many years 'we have pointers to functions, so lamdas are not that necessary', but lambdas was added and now they say 'oh, it is so cool'.

[vbcodec]

@jaredpar
While source generators may be problematic, but replace / original is free from such problems and code is delivered by developer, and this feature should stay in release. Replace / original is orthogonal to source generators, despite that they can be used together to provide highest potential.

[CyrusNajmabadi]

As a language designer, one of the things i steadfastly work to avoid is adding a feature too early. For example, say we added replace/original in this release. Then for the next release we really tackled SourceGenerators. Let's say during that process we realized that replace/original was just not going to cut it and we would have to add something else that worked slightly differently but still shared similar goals and functionality.

Now we're in a situation where we've got to maintain this feature from every moment forward. We also have to consider how this feature impacts everything else we do in every successive release. That's a burdensome tax that will hang around us forever and which will _definitely_ slow down our release cycle.

I think it is very important that we put features in when we feel that they're not only great, but really make the most sense for the future of the language.

[miloush]

I always welcomed when the team decided not to push a feature into the release were they not 100% happy with it. Sometimes it prevented including things I personally found frightening, sometimes it prevented features I was looking forward to. Either way, it gives me a feeling of quality control in the process and I know that whatever makes it to the release is backed by sound design and firm belief of a team of experienced people that it is _the right thing_.

Unlike @MgSam, I think C# is evolving pretty fast, actually. You can't please everyone, but everyone can now try their own ideas and see how far they get. And if another language fits your task better, use that one instead.
I agree that tooling is critical, if the IDE does not support it, the feature is practically dead from the beginning (XAML 2009, multi-module assemblies, ...)

I am also not concerned about the language "popularity". At the very least, I am not convinced that the fact that a language is so confusing that people have to ask questions about it is a good sign of anything.

[AnthonyDGreen]

Hey all,

@jmarolf suggested that one way we could give you more insight into what we've been working on is by posting a summary of our end-of-sprint review. So I posted the summary here. Check it out. There are some bits of work that aren't yet public but I figured it was better to let you know that there was activity on stuff that you just can't see yet that's taking up some of our time and attention. Let us know if you think this kind of summary is helpful to you. You can find the summary here: https://github.com/dotnet/roslyn/issues/12974

[eyalsk]

@CyrusNajmabadi

It's not that "people got waaay too caught up in the comparison". The point in the responses was to show why such comparisons are not suitable as different languages have different goals and issues they have to consider which can dramatically impact things like language velocity.

You cannot simply compare one language to another without considering deeply all the issues and concerns they have. There are pros and cons of the different sorts of approaches and release velocity is one factor among many.

Frankly, being more transparent and more engaged with the community has nothing to do with the product, it has nothing to do with complexity, it has a lot to do with the people working on the product and the process itself.

When we compared TypeScript and other teams at Microsoft to how things are done here we simply wanted to show that there are some teams that are doing it right and it's working for them, we didn't really compared products but we were speaking about the process of these teams working on different products, and when I speak about process in this discussion I really mean 1) How teams organize information? 2) How teams deliver this information to their communities? 3) How often this information gets to the community? these sorts of questions has nothing to do with how how mature the language is and how complex it is.

One of the things that I really think the team should do or at least start at is write a document that explains the current process and moving forward what it's going to be like.

Sorry if I've been blunt or harsh here, it isn't my intention to be disrespectful.

@AnthonyDGreen, @jmarolf and for the rest of the team thank you very much for posting the sprint summary, this is a great start!

[ljw1004]

@MgSam wrote: _"This means C# 6 and 7 will ultimately be syntax sugar releases."_

Also, async ValueTask which is a small feature, but not syntactic sugar, and it does open up a new way of coding -- libraries with async for their inner loops.

[vbcodec]

@CyrusNajmabadi

Let's say during that process we realized that replace/original was just not going to cut it and we would have to add something else that worked slightly differently but still shared similar goals and functionality.

Say 'hello' to my proposal #7300 where I've expressed scepticism for source generators and replace / original. Looks like team realized the same issues, mainly low performance and polluting language with unnecesary features. I've muted my scepticism when these features were promoted to 'high interest', but now I have new more complete proposal, that replaces rejected features, while preserving their goals and potential.

• Make methods / properties precedence for partial classes. Function / property in partial class will have higher precedence than function / property in non-partial class. The same function in two partial classes won't be allowed and raise error. This precedence will allow for 'code injection', which will be complementary to existing 'methods, properties and fields injection'. This will fix many issues while using partial classes.
• For AOP use IL code generation driven by metadata (similar to Postsharp). Alternaltivelly it may be implemented evem for JIT / Native code generation and will be available for any net language, but CLR team must be engaged This will save precious space in languages for better features
• Move source generators from Roslyn level to Visual Styudio level. There is need for some basic tooling that will raise events when files (any type, not only with code) are modified by VS. These events for files are: creating , save , change content (keystroke), delete , include and exclude. These events will be handled by library specified by project's settings. This library will be placed in project's folder which will ease move project between computers without losing ability to generate sources, if changes will be made to the files.

[AdamSpeight2008]

@ljw1004
Will there be an async valuetask analyser, that suggests a async value task could be a better approach.

[gafter]

@vbcodec

Let's say during that process we realized that replace/original was just not going to cut it and we would have to add something else that worked slightly differently but still shared similar goals and functionality.

... Looks like team realized the same issues, mainly low performance and polluting language with unnecesary features. I've muted my scepticism when these features were promoted to 'high interest', but now I have new more complete proposal, that replaces rejected features, while preserving their goals and potential.

Nothing has been rejected. @CyrusNajmabadi was just explaining that we have held back the replace/original feature until we have complete confidence that they fully solve the generator scenarios - which we will demonstrate by shipping them together when all the tooling is ready.

[CyrusNajmabadi]

:+1: on what Neal said. We still like this space, and i'm personally a fan of this source-based approach. But if we can't do it well, we should not rush something incomplete out the door. I'd much rather us spend the time necessary to make something amazing.

[vbcodec]

@CyrusNajmabadi , @gafter
I am still sceptical especially for replace / original as tool for AOP (probably single important case for this feature). For simple AOP, replaced classes end up providing wiring (OnEnter/OnExit) to AOP system with linked subscribers. For more demanding AOP replaced classes will contain modified code copied from original methods, effectively doubling amount of code. This will decrease performance of editors to new level of sluggishness, as of today on newest CPU I can't avoid multi seconds pauses. This also will increase problems with source generators, where generators for C# can't be used with VB, and vice versa.

Better option is extensible system based on metadata and IL codegen, that will solve these problems created by replace / original.

[CyrusNajmabadi]

We should leave the discussion of SourceGenerators to appropriate threads on that topic. It would be inappropriate to get into a long discussion on that topic here. The core point i was making was that we believe it's better to spend the time to get features right, versus delivering potentially wrong features too early.

[eyalsk]

@jmarolf Is there anything going on with this website we proposed? or it's something that will come in the (shamelessly) far future?

I know you guys are probably very busy for RTM but can we expect to have one after it? I guess that's what I'm really asking. 😄

[jcouv]

The thread seems to have settled. I'll close the issue.
Meeting notes are now getting posted at https://github.com/dotnet/csharplang/tree/master/meetings/2017