VBLang Repo lacks clarity

[KathleenDollard]

The vblang repo lacks clarity, particularly in terms of what can be expected to be worked on. @bandleader described it as "a mess" in .

From @bandleader's comments:

• there are tons of issues with no response from Microsoft at all
• many issues are describing scenarios that should be combined into one feature (must create issue for the full feature, describe which issues this supersedes. take in the most accepted syntax/ideas of the other issues, then CLOSE them)
• some issues are not clearly defined, written in hard-to-understand English, or propose changes that cause grammar ambiguity (not everyone > understands compilers) or solve too narrow a scope of scenarios, and the issue needs to be clarified, corrected, and sometimes integrated > into a new issue.

Also:

• there are several issues that are different proposed solutions for the same problem.

I absolutely want to provide clarity to this repo and avoid anyone being forced to reopen existing issues.

Drawing ideas from other repos helps consistency, but this repo is unique in many ways. I think we will be best served if this repo serves as one mechanism for strengthening community. I assume this repo has been frustrating at times, and my goal is to reduce that.

This discussion is only for the VBLang repo. Other repos, like the Roslyn repo is an intense working repo that requires different and generally stricter management.

[KathleenDollard]

The VBLang team has committed to reviewing all open issues. This will take a while. I was going to work in reverse chronological order, but I think reverse chronological on last comment is best. So if there is something you want reviewed early, please make a comment - ideally indicating why you think it should be reviewed.

Issues should not state only a problem and not a solution. I believe it is absolutely critical to the design process to consider all possible implementations of a solution to a problem. You could both open the issue and include your solution as a comment, but all solutions and enhanced understanding of the issue would be comments.

I propose that we be rather strict on this, to the point of closing and either recreating or asking the author to recreate issues that do not follow this pattern. In the current state of the repo, this would allow a single place to clarify why Flags enums are difficult in VB, and see @AdamSpeight2008, @AnthonyDGreen and my ideas side by side - along with your ideas without having to get to the point of a formal proposal. This will also make it much easier to interact with the languages team who can more deeply gauge technical aspects of the solution.

As the team reviews issues, they will combine them and link as required to group. All issues that have been reviewed will be tagged. I don't intend this to always shut down that conversation - tell us if you think we are wrong. But I also don't for us to waste time.

I feel quite strongly that someone should be able to walk up to this repo and say "Wow, VB is considering xxx" and "Oh! VB folks are talking about yyy." I also feel quite strongly that problems be identified and then different solutions have a level playing field. I suggest we do that by having proposals will be considered only after an issue has been discussed. This avoids confusion about what proposals are under serious consideration and helps people that want to make a commitment only to respond to proposals. If you want more detail than you think make sense in a comment, that's great and you can use a gist or other place.

I have mixed feelings on prototypes. On the one hand, it's a way for you to determine if your idea makes sense and is doable. On the other hand, not everyone has the same capacity to build them. So I suggest that we allow prototypes (I think @AnthonyDGreen has some in mind, and I would not want to discourage him), but explicitly not allow them to tilt the playing field toward the prototyped version - beyond the obvious that it represents research completed. If your a VB leader, and I think everyone here is, then your ideas are very important and your contributions to community. Those are the things I want to encourage most.

@AdamSpeight2008 brought up adding a wiki, and I'm going to split it into VBLang/language transparency issues and community support.

A wiki / use of the projects feature on this repo would be a nice addition, may also attract contributor to pick off outstanding tasks.

Proposals
Need specifications written,
Proof-Of-Concept prototypes.
References to forks, so others could contribute or help develop it.
...

I feel that most of this is better solved with repo organization, and notes in the readme, so people new to the repo don't need to understand that this stuff is in the wiki. Plus some of this ("Needs spec..") can easily get out of date. But definitely a possibility.

[AdamSpeight2008]

@KathleenDollard
On Prototypes i think that we should have page dedicated to how to contribute features.

• Fork and branch the VRLang repo ( with the name of there feature / design )
• Include a Proposal specification,
  • This can be updated and pushed to VBLang as progress indication.
  • Link to the Issue your provide at prototype for.
  • How it provides a solution.
  • Link to your branch of the Roslyn include declaration of the state of implementation.
    • DON'T PUSH TO THE ROSLYN REPO
      • Without alerting them first.
    • Parsing, Binding, Lowering, Emitter. etc
    • Eg It mostly parse. It parses but don't compile. etc.
    • Any updates to the Tooling;- Colorisation, Formatting Code Fix etc
  • Issues with a specific prototype, should be raised
    • on then corrisponding repo
    • on the Pull Request.

[AdamSpeight2008]

@KathleenDollard
We should also have page that expresses the Language Style the developer can follow when implementing features. It may carry more weight if this came for the VB.net community, that the Roslyn may accept it.

[KathleenDollard]

@AdamSpeight2008

I'm assuming you just left out the first step - discuss as an issue that states the problem initially without a solution and allow all possible solutions to be discussed and noodled on. :)

We want to drop the "without alerting them first." That process will be that we'll take the issue/proposal that will move forward, and at that point we'll assign a team engineer to shepherd through our non-trivial internal processes.

So, basically, I agree we need to fine tune a set of instructions about how to contribute and just need to tune the instructions and the text. I think it also might want to include a mechanism (not sure what it is) to get help from this community, since the engineers really don't have cycles for that.

[KathleenDollard]

@AdamSpeight2008 On Language Style, doesn't this already exist in the Roslyn repo? I don't know why VB would be different than that.

[gafter]

I think it would be a good idea to keep the language repo and the roslyn repo separate from each other. The vblang repo is where we request language features, noodle on different ways the feature might present itself in the language, and possibly get buy-in from the language design group that a given design is OK to proceed, and possibly when.

The Roslyn repo, on the other hand, is where compiler work goes. It is where we talk about implementation ideas, coding guidelines, parsing, scanning, lowering, etc. We talk about feature design there, but not language feature design. For example, we might talk about changes to the compiler command-line flags, generating reference assemblies, warning waves, and other compiler-specific features. Once a language design has been tentatively approved (discussed here), a next step can be a prototype of the design (in the Roslyn repo).

We don't need to document anything about a particular compiler in this repo. We talk about the language design here. In the Roslyn repo we discuss implementation (one particular compiler).

[bandleader]

The VBLang team has committed to reviewing all open issues. This will take a while. I was going to work in reverse chronological order, but I think reverse chronological on last comment is best.

@KathleenDollard @gafter Here is quick bookmarkarble URL to the list of open issues, sorted by most recently updated:

• https://github.com/dotnet/vblang/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc

[KathleenDollard]

@gafter I agree. If I said anything that was not in agreement with this explanation of the repo differences it was not intentional. I appreciate your ongoing help in keeping things organized, and if I said something confusing, I'd love to clarify.

[gafter]

@KathleenDollard I think we are on the same page.

[AdamSpeight2008]

@KathleenDollard @gafter I'm on a different page / book.
VBLang Issues should be considered as scratch pad for Ideas where they are discussed.
The Roslyn LDM should only be discussing the Pull Requests with this repo not issues., as these are considered by the VBLang community as viable designs for incorporating into the Visual Basic language.
Roslyn repository is where additions to the feature official language specification is written, updates and correction can be submitted here as PRs for LDM to review.

We as community should be welcoming community members that want to the freedom to experiment and explore the VIsual Basic language. To see where the potentially the language could go, the VB LDM then decides to destination, not the map we are using.

[AdamSpeight2008]

In the current state of the repo, this would allow a single place to clarify why Flags enums are difficult in VB, and see @AdamSpeight2008, @AnthonyDGreen and my ideas side by side - along with your ideas without having to get to the point of a formal proposal.

@KathleenDollard
Interesting use of language within your reply., which suggests (to me) a division of you (the Roslyn side of VBLang repo and the VB Community see this repo.

This will also make it much easier to interact with the languages team who can more deeply gauge technical aspects of the solution.

See my previous reply for a how this could work.

[AdamSpeight2008]

@AdamSpeight2008
I'm assuming you just left out the first step - discuss as an issue that states the problem initially without a solution and allow all possible solutions to be discussed and noodled on. :)

I left it out because I was discussing Prototypes, the problem would have be already touch on.

[AdamSpeight2008]

@KathleenDollard If there ain't any notes from LDM swhere VB.net has been discussed on the Repo, effectively for the rest of the community that meeting never took place. Any decisions or feedback never happened. Hence why they feel out of the loop and as second class citizens.

[bandleader]

@AdamSpeight2008 The Roslyn LDM should only be discussing the Pull Requests with this repo not issues.

Why? This repo is for language design -- we suggest language features to add to VB, and not necessarily their final implementation. (Most of us aren't very familiar with the Roslyn codebase, and won't be contributing prototypes, but have valuable input on features, which we contribute in the issues.)
The actual changes to Roslyn (including spec changes) are done in the Roslyn repo, either by the good folks at Roslyn team that MS pays to do so, or by generous community members like yourself. In the past @AnthonyDGreen would present the issues at the LDMs and that's how they would move forward.

[AdamSpeight2008]

@bandleader
I'm saying in Language Design Meetings, they should prioritise the VBLang Pull Request over Issues.
So they can progress to the next step and not be left to stagnate.

[ericmutta]

@KathleenDollard The vblang repo lacks clarity.

I definitely understand this sentiment. One of the things I hope you could address, is to have the members of the language teams introduce themselves and their roles (not all their github profiles are complete). This would help us know who to talk to about what, instead of doing what we did earlier which was tag @AnthonyDGreen on pretty much every single issue reported here.

The man is a MACHINE and I was always amazed how he found time to respond in great detail, though in practical terms that is unsustainable. We need the other VB langauge team members doing the rounds here as well so no single person is overloaded with the task of responding to issues.

I would also suggest the appointment of a Community Contributions Champion (or some such) whose sole mission in life is to do everything humanly possible to increase the number of non-Microsoft people who can contribute real code to Rosyln, which is a non-trivial codebase. This would be a "hand-holding" role designed to help community members go "from idea/bug/issue/proposal to an accepted pull request".

It could be a dedicated person or it could be a role every team member is required to play (a kind of "community service"). The long-term objective is division of labour, so Microsoft can work on "big picture stuff" while the community works on prototypes, bug fixes, minor pet features, etc.

So far, the only one I know among us that has gone as far as making a prototype for any issue discussed in this repo is @AdamSpeight2008. The role of the Community Contributions Champion would be to increase the number of @AdamSpeight2008's among us. It may be a temporary role but I believe it is a necessary role to help along the transition from closed to open-source.

Speaking from personal experience about this transition to open source: the VB compiler has been a black-box to me for 20 years. For that period of time I have learned NOT to peek inside the box because it was never an option. Then Rosyln happened and the box was opened, so now some of us are peeking inside but still not putting our hands in there because again: that was previously never an option and we learned NOT to try it. It is a culture bug and I believe it won't magically fix itself (hence the need for a champion).

In summary: Microsoft made an AMAZING decision to open-source Rosyln and to create a community edition of Visual Studio. Giving it all to the community is step one. Actively helping the community give back is step two. Without step two (i.e the community giving back) then step one (i.e Microsoft giving to the community) is reduced to a welcome, albeit pointless act of charity (I say pointless because if the code was closed today, I dare say few would notice any effect...which is a crying shame given how much sweat, blood and tears must have been shed by valiant un-named individuals to make open-source Rosyln a possibility).

[gafter]

I'm saying in Language Design Meetings, they should prioritise the VBLang Pull Request over Issues.

The language design meeting does not perform code reviews. They perform language design. If you have a language design issue, open an issue for it. If you have an idea for a new feature, open an issue for it. Opening a pull request for an implementation of a proposed language feature won't get any attention from the language design meeting unless there is an issue describing the proposed language feature in detail. Even then, it may not get any attention unless one or more members of the LDM think it is worth spending time on.

[AdamSpeight2008]

@gafter I never mentioned anything about code-reviews. Only that the LDM should process the VBLang pull-requests first. As they could contain updates to the documentation, "fully-fleshed" out proposals. etc.

[KathleenDollard]

I want to be transparent on a few things as of today, and also transparent that we will be evolving.

• At present and for the foreseeable future, there are no cycles for @ericmutta 's suggestion of a Microsoft provided Community Contributions Champion. We need people building features and that isn't their skill set. I would love it if community members helped each other and such champions emerged.

• The greatest value of open source is that we can talk about issues. After working to improve Microsoft products across many levels of secrecy I feel it is impossible to overstate the importance of this. An open dialog with even a small number of users, balanced with our best guess of the broader user community is the critical value OSS brings here.

• For a while language features will be discussed in what may seem a random manner. The goal is to find features with the greatest value to the community that we can land. I hope the seemingly random manner of the next weeks will settle out as I transition into the role and we tie up some loose ends. It's been a lot to pick up. Issues will be considered as the value of solving the underlying problem, as many approaches as we think of and have been proposed, and without bias to prototypes. This is the best way to build the best Visual Basic.

• We are not blocking community contributions. They just need to go through the same process as internal work. That includes the above (real value? excellent bang for buck? other options? etc) and that all features have an LDM champion. The LDM champion for a community contribution will shepherd things through the MS system, as no one expects folks outside to understand that.

• The language team members are welcome to introduce themselves if they would like, but they won't all be answering questions here because that's just not how the team works. I'll cover responding to issues in this repo as will some of them. You already know the amazing @gafter.

• I will be working with other people at Microsoft on the Visual Basic issues that extend beyond language. While it is not language related, at least for now, these things can be discussed in separate issues here because I simply don't know a better place to put them and many of you have insight into language and ecosystem.

I believe all but the last is consistent with many other repos at Microsoft, especially the CSharpLang. The last item reflects the current state of the Visual Basic ecosystem support.

I cannot stress enough how important your insight is. If you are here, you care about Visual Basic and have an important voice. I appreciate the language and compiler depth folks like @AdamSpeight2008 and @billmcc have, but I care every bit as much about the opinions of folks in small shops that want VB to be easier to use and just have opinions on what is hard.

Kathleen

[zspitz]

I think an essential part of the wiki would be a document describing the goals of VB.NET. Having such a canonical description would make it easier for contributors to align their feature suggestions with the spirit of VB.NET; and also provide a standard first step in triaging suggestions, e.g. 'We are doing this, because it fits the goals of VB.NET' vs 'This is a non-goal for VB.NET, so we're not doing it.'

Something like this document describing Typescript's goals.

As a side benefit, the goals/non-goals listed in such a document would be useful to anyone who has to answer the 'Why use VB.NET?" question. If a developer know that the design goals for the project align with the VB.NET design goals, he or she will be more interested in using VB.NET for said project.

To start with:

Goals

• English-like syntax (except for basic mathematical operators, member access and parentheses)
• Corollary of the above -- Avoidance of non-character symbols
• Backward compatibility with previous versions
• Consistency with other language constructs (e.g. Function(x) for lambda expressions matches Function MyFunc())
• All else being equal, use the simplest syntax
• It's OK to resolve ambiguities with the simplest / most common use case (e.g. type inference for lambda expressions)

Non-goals

• Syntax like Language X because "they did it that way"

[ericmutta]

@gafter Even then, it may not get any attention unless one or more members of the LDM think it is worth spending time on.
@KathleenDollard The language team members are welcome to introduce themselves if they would like...

Here is a tough question: do you see the conundrum here? On the one hand, you can't get a language idea implemented unless someone on the LDM champions it (which is OK)...but on the other hand members of the LDM can choose to introduce themselves IF THEY WOULD LIKE...which ultimately means unless you work there, it is NOT CLEAR who exactly is on the LDM and how you can get them to think something is worth spending time on.

I understand there may be legitimate reasons for all of it but it does make the experience of submitting issues to the vblang repo feel like a trip to the casino where the best you can do is hope something good will happen.

I remain optimistic that over time this will improve and things will be like with the rosyln repo which feels like it is manned by an ARMY of issue handling JEDI who can fix bugs even on Christmas! 💪

[gafter]

Here is a tough question: do you see the conundrum here? On the one hand, you can't get a language idea implemented unless someone on the LDM champions it (which is OK)...but on the other hand members of the LDM can choose to introduce themselves IF THEY WOULD LIKE...which ultimately means unless you work there, it is NOT CLEAR who exactly is on the LDM and how you can get them to think something is worth spending time on.

You don't need to know who the members of the LDM are to post an issue with your idea. You don't need to call them out by name. LDM members look at this repo as their time permits. We also have plans to review the open issues from time to time, now from scratch since @KathleenDollard has started as the PM for the VB language effort. The way to get an LDM member to think something is worth spending time on is to have and describe an idea that we think it is worth spending time on.

[AdamSpeight2008]

@gafter Proposals that have supporting prototype,, can help the LDM evaluate them and people to play with the features to see if it suitable. We understand that the LDM may decide recommend not taking the proposal officially yet (or ever). The LDM can still have "LDM Approved Proposals", adding tags to issue / pull request will give a indication as the current status of an issue or pull-requiest.

[ Seen by LDM ]
[ LDM - Reviewing ]
[ LDM - Reviewed  ]
[ LDM - Declined  ]
[ LDM - Approved  ]
[ Unsanctioned ]
[ External     ]

But I the conviction that deterring people from doing them isn't in the spirit of opensource approach.
It promotes an animosity, that you can look but not touch. "IT's my ball and I'm going home."
The prototype implementer has considered it worth (at least for them) taking it further.
It's not like we're drowning in PR contributions especially from external contributor (Non Roslyn / Microsoft)

[gafter]

You’re welcome to develop all the prototypes you want, but a PR that implements something that the LDM has not vetted is unlikely to be tried by anyone at Microsoft.

[bandleader]

@KathleenDollard The VBLang team has committed to reviewing all open issues. This will take a while. I was going to work in reverse chronological order, but I think reverse chronological on last comment is best.

May I ask how things are going with this?

[KathleenDollard]

@bandleader

Yes, of course you can ask!

April and May have been heavy and non-overlapping conference travel schedules for Mads and I, I've been called to some take care of some family health issues, and I've focused short term efforts on exploring the possibilities within Anthony's proposal.

So, you are correct that the review effort has been stalled. I anticipate it restarting, but not until June when we are all back in the building.

Kathleen

[bandleader]

@KathleenDollard Too bad! but good luck. Which proposal of Anthony's do you mean?

[KathleenDollard]

@bandleader #282

[bandleader]

@KathleenDollard May I ask how progress has been in the last 7 months? We've been discussing the issues here on vblang, promoting those we think are important and the best solutions to each problem. How has it been on the MS side?

I saw your blog post a few days ago, but couldn't really discern what from vblang was on the radar except for a mention given to pattern matching for 16.2 (with no timeline mentioned either). Also, not to blame you but to express pain, but there has been almost zero involvement from anyone from MS anywhere on this repo, which makes it so difficult to know what's going on.

Also, while I'm sure you were very busy, LDM notes have not been posted for ~5 months.

[KathleenDollard]

@bandleader

We've been involved in two things - planning for .NET Core 3.0. Overall this is a non-trivial effort and I believe that getting WinForms, etc. right, in add to the Visual Basic runtime is important for many VB developers.

One of the things on my radar is to figure out a system for communicating the little things that are regularly going in to VB, like analyzers.

As far as being in this repo - we've been reviewing issues and tagging them to help communicate some of what we are thinking - but we've realized that this is a task that will take a while.

I'm specifically not commenting on most new conversations/ideas. I think it's super important to let things percolate naturally and I don't want to depress the conversation with the fact we aren't likely to get to new VB features for a while.

It would be great if I could give dates, but I honestly don't know. VB 16.0 will ship with C# 8.0 in .NET Core 3.0. Note that this is NOT Visual Studio 16.0. VB 16.0 will first be shipped in box in VS 16.n where n is not yet determined. VB version numbers will be out of sync with Visual Studio for a while. All we've said about .NET Core 3.0 is "2019." It's a significant effort and the first preview isn't out yet. When we stabilize VB 16.0, we'll be working on VB 16.1, with a priority on any debt we have working with C# 8.0 features.

That's just a lot of words to explain, that I don't know. It will be months before we look at new features in the language (VS and analyzers will continue to evolve). And yes, we've been a bit quiet due to that - but we haven't been entirely absent.

Kathleen

[zspitz]

@KathleenDollard Can we see some of the work being done? You mentioned VS and analyzers -- presumably that activity is visible in the Roslyn repository?

Could you call out some specific VS features and analyzers that are currently in progress? Obviously without commitment to some final date even for these tooling elements, or even what their final form might be, but something along the lines of "This is what we're considering now."