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.

[iam3yal]

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

[iam3yal]

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

[iam3yal]

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

[iam3yal]

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

[iam3yal]

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

[iam3yal]

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

[iam3yal]

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

[iam3yal]

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

[iam3yal]

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

[iam3yal]

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