How should we minimize/eliminate negative impacts to projects that opt out?

[jongalloway]

Splitting this out from #9 to make sure we don't lose it:

One thing that I already wrote on Twitter: it's perfectly fine for Microsoft to come up with a set of requirements that they give to the community and say: "look those are the things you need to do so that we can put your product into our stack". That would be a great thing if done by MS.

Putting the ladder into the foundation on the other hand makes it a thing that will spread to the whole community and will put pressure on projects that will never need to go into MS stack. People in companies will just blindly adopt it and now projects are called "untrustworthy" just because they don't align with a set of requirements that MS needs internally. That's not good

The readme does say we have a general goal of improving overall ecosystem quality, and we did anticipate some positive network effects by allowing L4 projects to take long term, trusted dependencies on other L4 projects.

However, we want this to be opt-in and to avoid or absolutely minimize any negative impacts to projects for which this is not a good feedback, for whatever reason: project unique technical constraints, wrong fit for how the project team works, or whatever - maybe it just feels like a poor tradeoff of extra process that's not worth it.

Do you have suggestions on how we should alter policies or program communications balance this better? We'd like to keep the positive ecosystem impacts for projects that opt in, and eliminate or drastically minimize the impacts for projects that don't want to or can't participate.

[terrajobst]

A related aspect is that it's not really opt-in vs. opt-out, it's that every rung on the ladder needs to be considered a valid end point for a project with no pressure. Nobody should be shamed for being "stuck".

[barnson]

@terrajobst Then the names of the levels really need to change, eh?