Replies: 49 comments
-
|
The team already has an open process for designing features which includes community feedback. Why should the team adopt a different approach? What does the current process not address? |
Beta Was this translation helpful? Give feedback.
-
|
What exactly would be the difference between the proposed process and the current one, apart from changing the name from "championed proposal" to "RFC"? |
Beta Was this translation helpful? Give feedback.
-
|
Seems that I was not clear enough. It is not proposal to do RFC for single features it is proposal to put list of features which are going to be included in next major release (perhaps with some minor point releases).
|
Beta Was this translation helpful? Give feedback.
-
|
Versions are not defined by a list of features decided in advance. They are comprised of the features that can be completed in the appropriate time frame. To add a process which attempts to time box the team and force a given feature to be implemented in a "next version" I believe would be very counter to how the language is designed today and would be a detriment to the overall evolution of C#. Many features slated for C# 8.0 have been in discussion and design since before C# 6.0. And not a single one of those features is guaranteed to be released with C# 8.0 either. |
Beta Was this translation helpful? Give feedback.
-
|
Why change something that's not already broken? If you want to make the argument for change, perhaps a good place to start would be to identify the problems you see with the current process. |
Beta Was this translation helpful? Give feedback.
-
|
I thought the general consensus was that the current process was kind of broken, where decisions were made about C# 7 releases long before the community found out about them and way too late to change course? |
Beta Was this translation helpful? Give feedback.
-
|
IMO that has been due to the periodic delays in releasing design meeting notes thus not giving the community a lot of (or any in some cases) time to review and comment. The team seems to be much more regular and timely with those notes lately. And I don't think it helps to have a process to try to corral proposals into a semblance of a release. The design process shouldn't be time boxed like that. |
Beta Was this translation helpful? Give feedback.
-
We already have this right here on the repo. |
Beta Was this translation helpful? Give feedback.
-
|
Hmm, is it a joke or simple an attempt to avoid any serious discussion. Could you point me to the issue in which addition of features to the milestone is discussed? |
Beta Was this translation helpful? Give feedback.
-
Sorry, but such argument says nothing. @HaloFour Could you elaborate and be more specific. |
Beta Was this translation helpful? Give feedback.
-
This consensus is really widespread and seems to be contested only by small group of most active contributors to the online discussions but not necessarily contributors to the language itself. |
Beta Was this translation helpful? Give feedback.
-
@theunrepentantgeek Why you think that process is not broken? Can you compare it with other languages developed as foss? My experience and observations tell something very much different. |
Beta Was this translation helpful? Give feedback.
-
It says that the community doesn't (and shouldn't) tell the designers when features should be ready to be included in a release.
First, any discussion on this repo represents a tiny minority of feedback that the language team receives. There are, what, a couple of dozen people posting here? And the people who have specifically posted that they want more control over the evolution of the language represents a minority of that minority. The C# language is not a democracy. It's been expressed pretty explicitly that the C# team remains the final arbiter as to what features will be added and when they will be added. I get it, you want more control and influence. The team doesn't want that. It's their language.
The onus of evidence lays on the individual making the claim. |
Beta Was this translation helpful? Give feedback.
-
|
One more important issue: I do not think that anyone serious could say that C# development currently is based on benovalent dictatorship. Such argument was raised in #1600 thread but never really developed. Currently LDM runs the decision process and interacts with community via this repo. Why not improve this interaction? One of the most precious and limited resource is developer time and using RFC to discuss it's allocation is something separate and different from discussing syntactic and semantic merits of proposed features. Honestly, it's hard to understand that such situation is continuing for several years already and any attempt to discuss it is pushed away by small number of posting parties. |
Beta Was this translation helpful? Give feedback.
-
Let LDM speak on the issue and I don't think that in situation in which you do not represent LDM officially and yet accept its dictatorship and the fact that your opinion is totally irrelevant and yet you say something. So why you are expressing it at all - its logically contradictory, right? |
Beta Was this translation helpful? Give feedback.
-
There is no such discussion, because assigning a feature to a milestone is entirely at the discretion of the LDM. Not to mention that features can move forwards and backwards depending on what the team views is feasible to attain for the given release window. |
Beta Was this translation helpful? Give feedback.
-
It's unclear to me why this would be an improvement. Instead of having each of those issues tracked individually, there would now be multiple locations in which it would be happening. Furthermore, this would be especially bad on a forum like github. That's because there is no proper threading. So now instead of having 10 individual issues, each focused on one specific langauge change, you have one issue with people talking about 10 different thins. That seems really bad. It feels like it would be extremely difficult to keep things understandable. Heck, when we have single issues today about a single language feature, it can often descend into complex conversations about subpieces of the single feature. Even this is difficult to deal with. So it seems really bad if this was compounded by having an RFC that merges these all into one thing. |
Beta Was this translation helpful? Give feedback.
-
|
This is a great discussion, and it's been really enlightening and encouraging to see the different viewpoints. Thanks all! As you know we've been fiddling with this process over the past several years, and are still making improvements. One recent improvement was getting a dedicated notetaker for the LDMs, who can communicate the outcomes back to the community with much more detail, accuracy and expediency than I was able to. Language innovation is a very fluid process, and very hard to box in. For every single proposed feature there is an unpredictable amount of design work, challenges and interactions with other features, as well as a high risk of failure, in that we often cannot find a design that lives up to our standards. The aspect of how much we want to add the feature can and certainly will factor into how much time we allocate to the design process for it, but assigning it to a release even tentatively comes with great uncertainty. Through trial and error we've landed on the milestone system for championed features. This process commits us to looking at a championed feature within a given timeframe. Oftentimes, though, "looking at it" leads to discovering that it's either less desirable than competing features or harder than we thought. Then we'll either remove it or kick the can down the road to a later release. This is far from an exact science, but it's actually working pretty well. Every artifact of this process is publicly visible on this repo. We don't do the planning "somewhere else" and post it here when we care to. This is our working space, right here. If you want to see what is being considered for C# 8.0, just look at the milestone. It is the responsibility of the LDM to ensure that we not only build the features right, but also build the right features. Obviously, "right" is in the eye of the beholder. We try to take an integrative view across the current needs of the whole community as well as the long term success of C# and the .NET platform, as we can best discern it. We all want C# to solve our problems today, and we also want it to be desirable and successful into the future: we're all to some extent betting our future on it. Last year I tried to formulate the philosophy behind our decisions in the .NET Language Strategy, so that the decision making framework itself is also out in the open. So now you can see what decisions we make, as well as how we make them, and why we make them, when we make them. When you don't like them you can influence us right here. |
Beta Was this translation helpful? Give feedback.
-
|
@MadsTorgersen @gafter @jaredpar @CyrusNajmabadi Thank you all for thorough discussion. IMHO we got to the core of the problem and it seems that the best way to reconcile different needs and expectation related to: (i) flexibility and unpredictability of development and thread/feature based issue tracking system and nature of design process on one side and, could be small change to current practice, actually, not a change but continuation of already existing practice. The triage of milestones done at the LDM meeting and here #789 discussed with the community is a great example. It will be very helpful if such process would continue. |
Beta Was this translation helpful? Give feedback.
-
|
@4creators Thanks! Yes, the triage happens in C# LDM, and so the design notes should generally bear that out. We're due for a new round of triage, but for a couple of weeks I've had to push it out from the agenda due to issues that were blocking developers. I think we'll get to it within a couple of weeks, and then the result will be in the design notes. Now that we're on the topic, the agendas are generally very late bound, especially at times like now where a lot of features are mostly figured out (for C# 8.0) and developers run into unresolved issues that we need to deal with quickly to keep them productive. When I know the agendas in advance, I sometimes put them up in the form of ahead-of-time design notes containing a proposed agenda. |
Beta Was this translation helpful? Give feedback.
-
|
Speaking of triage, I am concerned with the growing number of proposals that seem to be stuck in limbo. They're not "good enough" to be championed but also not bad enough to warrant being closed outright. It's be nice if those issues could see a little love from the C# team. I am sure that free time is something in short supply, but I think it would be useful if perhaps some time per month could be dedicated to a couple of these proposals during C# LDM. Perhaps they could be selected in order, or team members could "adopt" ones that they feel lukewarm about. Then the team could gauge a relatively quick level of effort and degree of interest. Those proposals that don't seem like they would ever really be considered could be closed and those that remain could perhaps be put up for community consideration as "up for grabs" or perhaps to a vote that could set a priority/order in which they might be implemented in minor releases. Lastly, while there is certainly interest in the community to actually try to implement a proposal, and a few success stories, I think we can all recognize that the barrier to entry is insanely high. Again, with free time in short supply I recognize that this might be difficult to implement but I could see value in a "community ambassador" program where members of the C# team help community members through the process of actually trying to make the necessary changes to Roslyn in order to implement new features. Just watching two members of the community engaging with a C# team member today over the possibility of implementing a feature was fascinating as the team member immediately could recognize the potential "gotchas" that would arise both due the nature of the feature and due to the architecture of Roslyn. Consider this all 🍝 against the wall. |
Beta Was this translation helpful? Give feedback.
-
|
Very good point @HaloFour - I made a couple of proposals that didn't go anywhere, and I just left them open. I'll go back and reconsider whether they should be closed or not. |
Beta Was this translation helpful? Give feedback.
-
I'd also add that anything that requires CLR or CoreFX changes is outright impossible for the community to wholly implement in our own time, as we have no access to or input into the .NET Framework BCL or desktop CLR to make corresponding changes there. |
Beta Was this translation helpful? Give feedback.
-
Tell that to the guy that's worked on implementing generic attributes with an associated CLR patch. 🙃 |
Beta Was this translation helpful? Give feedback.
-
|
@Joe4evr and the desktop CLR? |
Beta Was this translation helpful? Give feedback.
-
|
This may be a controversial view, but I think it time to retire the framework CLR. The future is with dotnetcore. What really is the benefit with MS maintaining two separate CLRs? This thread is an interesting one for me. A year ago, I'd have up-voted @4creators comments and rallied against the current process. But I've come to appreciate the way it works recently. This forum is dominated by a handful of opinionated folk. There's nothing wrong with being opinionated like this (at least I hope there isn't as I'm one of those opinionated folk), but we represent a tiny fraction of the C# user-base. If this forum were the course by which language features were chosen, then we'd end up with a language highly skewed toward what that small vocal group wanted, at the expense of everyone else. A case in point is scope leakage with "out vars". Many of us (possibly the majority) here were strongly opposed to this and ranted at the LDM for ignoring us. Some - especially myself - predicted mass confusion when the feature was released due to the different scoping rules. But the feature has been very well received by the user base as a whole. Folk I've spoken to aren't really interested in strict language rules etc. What they want is features that "feel right". Out vars "leak" in just the right way for them: it makes sense and makes the feature usable. The LDM made the right decision. They listened to us, but ultimately disagreed and took a different path that turned out to be the right one. If we had a process as described in the OP though, this wouldn't have happened and many users would have been unhappy with the results. I still think things could be improved here. Dealing with the hundreds of proposals that are stuck in limbo, having neither been championed on rejected, being the main one. But I feel the process around how features adopted by the LDM are discussed, prototyped and eventually released does work well. I don't think it is broken and doesn't need radically changing. |
Beta Was this translation helpful? Give feedback.
-
|
@yaakov-h I understood that the desktop CLR was actually built from the same sources or merged the same sources, but I could be wrong. |
Beta Was this translation helpful? Give feedback.
-
As much as I respect that (I don't believe a fully democratic process leads to a good design), I noticed something a few posts further down:
I find this document at its current version a bit puzzling because it appears to tell a slightly different story than the recent Building C# 8.0 blog post. That blog post names the following "most significant features slated for C# 8.0": Nullable reference types It stands to reason, then that the State column in the Language Feature Status document should reflect that these seven features have a common, fairly advanced state. However:
In turn, the 8.0 candidate milestone gives yet another list. (That list also doesn't appear to include Switch expressions. Maybe my google-fu is being poor here.) The name of the milestone also suggests that essentially no feature is currently a lock for 8.0, which surely isn't true, given that some have already been merged into VS16? Why not move those into a separate 8.0 (non-candidate) milestone? Lastly, the blog post also links videos that hype features that probably(?) won't make it into 8.0, such as extension everything. That's four different somewhat overlapping, somewhat conflicting sources on what will or won't make it into 8.0. I assume the blog post is the most canonical source for the time being. This may sound like nitpicking, but ultimately, I don't find it very transparent. It would help a lot if those documents were more in sync, so the community would know what the team is planning (vs. what is merely a wishful best-case scenario), and could give feedback accordingly. |
Beta Was this translation helpful? Give feedback.
-
In my experience the team is loathe to claim that any feature is "a lock" for a specific version until that version actually ships. We've seen features advertised and demonstrated for both C# 6.0 and C# 7.0 that did not ship in those versions for various reasons, such as
I think some of it may be interpretation of the current status of some of those features. Mads probably has the best idea as to what features are the most likely to make it, but I'm sure that picture changes slightly after every design meeting. Progress is difficult to gauge; all it takes is one hard question to derail the design of a feature. There's so much more R involved than D. I can certainly understand the sentiment, though. It can be quite difficult to get a clear picture as to what might be shaping up to be the next release, and I've been following it since Roslyn was first open-sourced. |
Beta Was this translation helpful? Give feedback.
-
|
Until we announce what future version of VS corresponds to what future version of C#, please do not assume. Also, please do not assume release dates or how advanced the implementation "should be" compared to your imagined dates. No feature is a lock for C# 8.0 until it has shipped. The document https://github.com/dotnet/roslyn/blob/master/docs/Language%20Feature%20Status.md describes what the compiler team is working on, not what language features are expected. However, there is obviously a lot of overlap. For the purposes of both specification and implementation, switch expressions are being treated as part of recursive pattern-matching, which is why it doesn't get a separate entry. But it is highlighted separately in the blog post because it will feel significant. You should not be surprised that previous, earlier estimates about the contents of C# 8.0 are different from more recent ones. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Following the example of open source communities working on compilers (F#, Rust) I would like to propose using open Request For Comments period for publicly communicating with C# language community about features which are going to be implemented by language, perhaps, about which features could be deprecated.
The RFC should be started by language team making an open proposal for next major release and discussion should continue until the deadline set in RFC. Received feedback could be a very good basis besides other sources for decisions which are obviously reserved for LDM.
This form of public consultation is one of the best ways to reach consensus and build strong community support for compiler, language and language team. Everyone who may have chance to comment will exert real influence on the language development just by following simple RFC process. Those who do not comment should not complain.
Related to #1600
Beta Was this translation helpful? Give feedback.
All reactions