Standards for IDE support

[jnm2]

Carrying on from https://github.com/nunit/nunit3-vs-adapter/pull/347#discussion_r124867822

I strongly feel that standards should be set as much as possible by each project lead independently from the Core Team.

The one standard I could see value in is to be as inclusive as possible for outside contributors. Things like which versions of VS/MonoDevelop/Project Rider can be used to build the repo and debug tests. But I don't want to restrict project leads unnecessarily.

1. Windows devs: Would it turn away outside contributors on Windows if a project lead is using a project format which cannot be built with VS pre-2017? Is this worth setting a standard on which constrains project leads? For example, if the project lead wants to use the new .csproj which can build all targets in one shot, should they also provide and maintain VS2015-compatible .csprojs, to the extent that it is possible?

2. Non-Windows devs: Likewise, should we enforce that people on Linux distros and Mac can also build all necessary project formats using freely available software, to the extent that it is possible?

3. Roslyn design-time reference: When it comes to C# (or any other) language version, I strongly vote that we put no restrictions on the version. If we do decide that we want to enforce point 1 above so that VS2015 can build every repo, this means we will require project leads to reference the latest design-time roslyn compilers NuGet package from every project that does not constrain the language version to 6. (If we don't decide to enforce point 1, then nothing has to happen here at all.)

4. <LangVersion>: I do think we should enforce the standard that if a project lead decides to restrict the C# version, such that PRs that use newer C# are bounced back for changes, every .csproj where that restriction applies must have the <LangVersion> set. This is for the sake of outside contributors and makes everyone's life easier. But we still recommend that project leads consider not restricting the C# version.

The way I'm thinking now, it would be ideal if we enforce points 2 and 4 only. What do you think we should consider?

[CharliePoole]

Our rule already is that project leads set the standards for the project, at least that's how I intended the docs to be read. To your points...

1. I think that a project lead should maintain backward compatible solutions where appropriate. I don't think it's a governance issue, however. The lead's team and collaborators and users have to tell him if he messes up.

2. Again, we have a doc (Vision) that says we support Linux. So we should except where it's obviously impossible, as with a VS extension. (BTW, it is a bit weird and off-putting to make Windows a special thing and have a special rule for Non-Windows devs)

3. This seems like something for the software team to do or not.

4. It seems like a really good idea to do this. I don't think we should "enforce" ( see below ) this.

I don't even know what it means to "enforce" a rule from the core team level. Does that mean we would have an inspector who looks at everything? Seems really time consuming.

Basically, this all sounds like stuff a well-run software project might want to do. But if done from the top it seems like micro-management. There are much better ways to carry this off. For example, you just made a comment on a particular PR that the <LangVersion> element should be added. I'm sure your advice will be followed. Why would we need to write a policy about it?

[jnm2]

@CharliePoole This is in response to you saying C# 6 is the standard and:

Strictly speaking, I should have said "has been the standard" up to now. The core team has to eventually decide what, if any, standards are imposed on projects. Meanwhile, I'd say it's up to the VS team lead and team.

So hopefully this is where we decide what, if any, standards are imposed. I don't know what it means to "impose" a rule from the core team level either, but let's discuss.

Why would we need to write a policy about it?

So that contributors and maintainers can look at something and know what to expect and how to proceed. My preference is that it isn't even a policy but guidelines based on core principles.

(BTW, it is a bit weird and off-putting to make Windows a special thing and have a special rule for Non-Windows devs)

That element is entirely intrinsic to the conversation because of VS. Once VS for Mac is up to speed (it's pretty close already) it'll be Windows and Mac vs Linux. Again, how important is it to us to not be off-putting? Let's discuss what we can do about it.

[CharliePoole]

@jnm2 Exactly... this is where we would decide about standards being imposed. As you know, I advocate very thin standards for teams. For managers over teams, I advocate zero standards... or at least nothing more than telling the teams they should have a standard of some kind and might want to consider writing it down.

So, I answered you about the four items and which should be imposed: none of them in my view.

As a governing body, we should advocate and encourage good practices by the software projects we originate or accept. We may want to have a limited set of written standards. We might also want to write some advisory guidelines, as for XML documentation. To me, that's about it. We are management when we put on our core team hats and we should be looking at whether projects are delivering software, fixing bugs, helping users.

[CharliePoole]

BTW, C# 6 is about the only coding standard we have decided as a body up to now. At least IIRC we said that the "Key Projects" should use C#6 as the standard.

[ChrisMaddock]

I think this issue came to an agreement that this is outside the scope of the Core Team's responsibility.

[jnm2]

Yes, thanks Chris!