Brainstorm: How can we improve communication and increase visibility?

[mousetraps]

Lately we've been working with a bunch of folks internally to ensure we have a compelling and cohesive Node.js story across the board, and also take care of some of the big ticket items for NTVS vNext that require major architectural changes and coordinating with many partner teams, each with their own timelines. This includes working w/ the TS team on Salsa support as we plan to make that the default IntelliSense experience within NTVS going forward, seeing how we can consolidate efforts with VSCode, TS, VS Web Tools, Cordova, etc. so that we can reduce duplication of effort, and much much more. Additionally we actually have open positions, so we've been focusing on recruiting and growing the team so that we can move faster going forward.

Unfortunately these efforts are not externally visible, so we should try to make an extra effort to communicate them going forward. To start things off, here are some ideas I had to increase visibility:

• post a clear roadmap that includes some of the initiatives that don't make it into the codebase.
• if there's enough interest... regular Skype / Hangout to discuss status, brainstorm ideas, and answer any Qs people have.

Thoughts?

[NoelAbrahams]

@mousetraps, I think a roadmap would be a good start. I suggest moving away from the current monthly release cycle to simply releasing versions when they are ready, 1.2, 1.3... 2.0 etc. It's hard to maintain a regular release schedule, and from the user point of view, when targets are not hit it sends the wrong message.

The roadmap should list the big ticket items that are going to be fixed in each version. For example, I would really like to see performance improvements to the test harness; I should be able to look at the roadmap and see when it's likely to be fixed.

GitHub is generally good for discussions. It might just be a case of promoting NTVS through Microsoft or through a release notes blog on MSDN in order to increase awareness and get more GitHub stars and watches. Fundamentally though, the project needs to be seen as actively developed, with lots of commits and meaningful feature releases. That will get people involved.

[mousetraps]

@NoelAbrahams thanks for the feedback 😃. Proposal below on how we should proceed going forward (and of course, we'll continue to experiment and evolve our approach as we learn what works and what doesn't.)

Rhythm and Roadmap

There were a couple key questions to answer here:

1. What are our targets?
2. What is our cadence?

Driving principles

And before we can actually answer these questions, let's take a step back and try to understand some of the constraints we are operating under.

1. We to coordinate our efforts with several partner teams. This means that we need to establish a regular cadence in order to effectively align timelines.
2. We have a small core team - we are hiring, but the fact is that the team is small enough such that it is difficult to make hard date commitments.
3. Ability to re-prioritize and quickly react to unexpected platform changes and other learnings - this is one of the challenges of building on top of a fast-moving platform.
4. Provide flexibility for people to work on issues they are most excited about.
5. Maintain a drive towards a long-term vision (in other words, let's not chase butterflies 😃)

As you may have gathered, the constraint _#_1 is at odds with _#_2, _#_3, and _#_4 - we need to establish a regular cadence, but it's difficult to do so because we have a small team and need the ability to react quickly. So we have to get creative...

The plan

We will have three milestone targets:

• Monthly "Big Rocks" - this will enable us to establish an ongoing rhythm and also align with the cadence of our partner teams. But it will differ from typical monthly milestones in that it will only list the "Big Rocks", the monthly "MVP", if you will. Over the course of the month, we may very conservatively move items into this milestone if it makes sense.
• On Radar - A pool of issues that are high on our radar for next releases, but we are not making any firm commitments to - sometimes, some of them may get pulled into the monthly, sometimes not. These will be triaged appropriately as the list grows in size.
• Future - not on our immediate radar - mainly a marker so that we know what issues we've triaged already.

In order to ensure that we are driving towards a long-term vision rather than simply reacting month-to-month, we will have an evolving higher-level Roadmap that highlights some of the guiding principles, major painpoints we're looking to solve, and general execution approach.

Building momentum

Some thoughts to address this point:

• we will, of course, continue to promote NTVS both internally and externally. The more content the better, but ultimately we are people-constrained. That said, we're always open to ideas for high-impact activities.
• We are currently working on consolidating some of our engineering efforts with partner teams (VSCode, TypeScript, Cordova, ASP.NET, etc.) - reducing this duplication won't result in immediate product changes, but should make it easier to keep up a healthy pace going forward.
• Making it easier for our users to contribute back by migrating code from C# -> Node.js. One of the challenges we have with building up an external contributor community is that our userbase writes in Node.js, but NTVS is mostly C#. This also fits in with our goals to consolidate some of our engineering efforts with Node+VSCode.
• We are hiring, but of course there is some upfront cost to bear - recruiting/hiring/ramping people up takes time.

Thoughts?

Anyways, it's getting a bit late here, and I probably missed some things, but I think this is a good place to start. As I mentioned, this is going to be a constant evolution, so feedback is much appreciated 😃

[mousetraps]

In accordance with the proposal above:

• Planning Notes
• Milestones
• Write high-level roadmap / charter #696 Write high-level roadmap and charter.