Proposal for a better feedback loop with extension authors

[eamodio]

Refs: #84506

Hi everyone — you may or may not have already heard that I have recently joined the VS Code team. Since joining, I've been working on bringing more of the outside voice into many aspects of the project — including extension development and the extension authors community. In that spirit, below is a proposal for how we can improve our interactions and support of the extension authors community. Looking forward to hearing your thoughts and feedback!

-- Eric

---

The extension ecosystem is incredibly important for users of VS Code and for VS Code itself. As such, anything we can do to help extension authors be happier and more productive improves the quality of this ecosystem. With that in mind, we’d like to create a tighter feedback loop and create a community for extension authors where they feel welcome and free to ask questions, voice problems, and provide feedback on evolving and upcoming extension APIs.

Goals

Let’s build a better, more collaborative extension ecosystem together. We believe that closing the feedback loop with extension authors will help us better understand their needs and help them to build better extensions, more effectively. Giving extension authors a channel to feel heard and appreciated will also help nurture that valued community. Beyond just extension creation, the management and tracking of extensions is also an important area to improve. We also need to make sure that people interested in building extensions have what they need to get started and feel welcome.

Open communication for the challenges of extension authors

Today, extension authors use GitHub to open issues regarding APIs and issue they run into, but we don’t hear much from the extension author community about what features are missing for them in the marketplace. We also believe that some discomfort is never reported because authors may feel it's not important enough to open an issue or that an issue isn't the right mechanism for being heard.

Get early feedback for on proposed APIs

As the team introduces proposals for new extension APIs, tracking issues and samples are created. While recent changes to the API proposal process, should make it easier for extension authors (and the wider community) to follow along and provide feedback, we believe a richer, high-fidelity channel for collaboration will improve things even further. By providing a direct feedback channel between the engineer working on a specific feature or features and the most-likely consumers of them, we can get better, more collaborative feedback, faster.

Monthly Meetings

Each month, @eamodio and @fiveisprime will lead an extension authors meeting. This meeting will happen toward the end of the iteration. At the start of an iteration, an issue will be created and posted containing when and how to join the call, the topic(s), and an agenda (as outlined below), as well as who should attend, if the topic is targeting a specific community for feedback (e.g. the scientific computing community). Ideally, we'd like to limit the audience to 6-8 people to facilitate richer, more effective communication. Also, as with the iteration plan issues, the previous meeting’s issue will be closed once the next one is posted.

While the agenda is very likely to change, the current working plan is below.

• [10 min] Follow-up on any open issues from the previous meeting
• [~20 min] Introduce topic and related new features and proposed APIs, if applicable
• [~30 min] Open discussion

Topics will likely be chosen based around the work in-flight on the current iteration plan, but we may also open topics up to some voting to provide a platform for extension authors to present and learn from one another.

Finally, at the end of the meeting, highlights will be posted to the meeting issue and any action items will get individual issues created and linked to the meeting issue.

There may also be a second, more ad-hock meeting with extension authors that is less structured for getting to know the authors and listening to their feedback.

Feedback

This plan is a draft of how we are thinking of moving things forward, but we are very open to feedback as to what the community thinks and needs. So please chime in and leave your thoughts and feedback.

Thank you!

Open questions

• What’s the best time to have this to include as many time zones as possible? Rotating time from month to month?

• How best do we limit the audience (6-8 people) for each meeting? As a smaller audience facilitates richer, more effective communication.

• Should the calls be recorded for public consumption? Would that have too much of a negative impact on candid conversations?

[lcampos]

This is a cool idea. It would be great if those meetings can be recorded. Since the audience is limited to 6-8 persons per meeting, it would be nice to have a way for those not attending it to pre-submitting feedback/questions that can be covered during the meeting.

[eamodio]

Yeah, I do think the benefits of recording them ultimately outweighs the negatives for the community. We could also explore having a portion of the call that isn't recorded (like at the end or something) for that more sensitive or candid feedback/discussion if needed.

And definitely like that idea of submitting questions -- although can't guarantee we'd always get to them.

[ppezaris]

You raised questions about how to limit the audience, and whether the meetings should be public. My $0.02 is that a private closed meeting with a small # of participants seems rather antithetical to the stated goal of increasing interaction with the extension authors community.

So I'd suggest either wider participation, or making the meeting recordings public.

Submitted questions seems like a natural way to include outside voices, so +1 to that idea.

[glennsarti]

What’s the best time to have this to include as many time zones as possible?

While my initial thought is two timezones (US friendly + EMEA friendly), Although I imagine with only 6-8 people the timing is really going to be dependent on the participants e.g. I'm in Australia, neither of those two times are friendly to me (or anyone really in the GMT+8 space)

Which brings me to the next point ...

Should the calls be recorded for public consumption?

These meetings MUST be recorded. No question! Firstly for those of us that are interested and can't make it (timezones, family stuff, work etc.), and secondly as a point of reference in the future. As @ppezaris mentions, it seems very strange for VSCode and the bulk of extensions to be OSS, and yet community engagement is closed.

A good example of this is the PowerShell Community and DSC Community calls hosted by Microsoft (Shoutout to @TylerLeonhardt and crew). Open planning, which is recorded, with notes, is a fantastic way to engage with the wider community.

Would that have too much of a negative impact on candid conversations?

Even it it there are negative impacts. This feels (mostly) no different that candid conversations via GitHub Issues/PRs.

So, in essence, it doesn't put the community engagement in a worse position, it can only get better.

How best do we limit the audience (6-8 people) for each meeting?

That's a really tough question. Although I think the idea of having a small number of people chatting and moderated questions is a great idea.

This sounds similar to how Speaker Panels work in conferences. Where a whole bunch of people are listening to a small group of people on stage. So perhaps take a cue from that, and use a CFP (call-for-proposals) style to find people. e.g.

(Example only, not a fully thought out process!!)

The VSCode Team (i.e. @eamodio) creates a list of ~12 topics. Community members can then submit themselves and pick up to 3 of those topics they feel they can speak about.

The VSCode Team can then select people from those submissions. That would give you one years worth of meeting content!

---

My only concern would be which people to choose. Because given the large number of extension authors and the size of the potential community engagement, someone somewhere is going to feel left out. Potentially (not saying it will happen, but) this kind of engagement process can turn into "only those people with greater X number of active users have a voice" kind of thing. Which can alienate sections of the community.

For example, while the PowerShell community calls are great, they ONLY happen on a West Coast US friendly time. For me, that's 2am, so I can't actively contribute and I have to go above-and-beyond if I want to. At times, it feels like that only the US community matters.

---

I am very excited to see the feedback loop revisited and I have really high hopes this makes my life as an extension author better.

PS ... and I just saw how long this response was. Congratulations for reading this far! 🎉

[gjsjohnmurray]

@eamodio I think this is a great idea and I'm keen to be involved.

[Almenon]

What’s the best time to have this to include as many time zones as possible? Rotating time from month to month?

Sounds good to me.

How best do we limit the audience (6-8 people) for each meeting? As a smaller audience facilitates richer, more effective communication.

By "audience" I'm assuming you're talking about speakers. I would let anyone join the meeting but have everyone be muted by default and only let the speakers unmute. Other people could simply listen in or write text comments if they wish. The speakers / meeting administrators wouldn't have a obligation to address the text comments but could do so if they wish.

As for choosing the speakers, that's a tough question. Choose randomly among those who express interest maybe? I like @glennsarti 's idea too.

Should the calls be recorded for public consumption? Would that have too much of a negative impact on candid conversations?

The calls should definitely be recorded.

There may also be a second, more ad-hock meeting with extension authors that is less structured for getting to know the authors and listening to their feedback.

I like this idea. There are thousands of extension developers and a less structured secondary meeting would good to capture more feedback from the entire community.

---

I'm also interested in attending these meetings depending on topic / timezone.

[TylerLeonhardt]

I've been bugging VS Code team members for something like this for quite some time so I'm definitely in and am happy to be a part of any sort of feedback sessions!

So excited for this!

[eamodio]

Thank you for all the feedback so far!

It is definitely clear from the feedback, that we should record and publish these calls. We are currently looking into using a live-stream solution where we can have a larger audience, but a small group of participants, and also have the stream available for viewing after the call.

We haven't yet decided on a time zone for the first call, though we are currently leaning towards late morning in EST. I'm curious though, would those who are interested in participating, is during the normal work day acceptable or is after-hours better?

Also not decided yet, but I'm thinking that the plan for the first call will be to keep things quite light on content and more about getting a feel for this, and meeting each other. So with that in mind, what do you all think about the first topic being something like "If you had 2 wishes to change/fix/improve VS Code and the marketplace, what would they be and why?". I'm also open to other suggestions.

Ask for on-going topics, I like the @glennsarti's thoughts of creating and vote ranking a set of topics, especially to have on-deck to choose from.

[gjsjohnmurray]

@eamodio the normal working day is acceptable for me. I am usually 5 hours ahead of Eastern. And that first topic sounds like a good icebreaker.

[TylerLeonhardt]

Any day or time works for me. I'm in PST so EST is doable.

"If you had 2 wishes to change/fix/improve VS Code and the marketplace, what would they be and why?"

This seems good. I'll just leave my first wish here 😶

[TylerLeonhardt]

leaving my second wish so I remember. This autoclose process has gotta be better for extensibility issues that would get less likes than regular user issues.

[eamodio]

Maybe also think about 1 or 2 small quality-of-life improvements that can be done to help you all be happier/more effective/productive/etc.

[rmunn]

This autoclose process has gotta be better for extensibility issues that would get less likes than regular user issues.

Case in point: as of right now, #58619 is currently at 53 votes. #73047, which is basically the same request as #58619 but for an extension (Powershell) rather than for VS Code itself, is at a grand total of 2 votes. Extension issues don't get nearly the same attention as issues that affect VS Code itself, so a threshhold of 20 votes for extension issues is probably too high.

[RandomFractals]

just catching up on this. This is a great plan for moving forward with getting more direct and less formal feedback from extension authors.

My only suggestion is I think there should be a representative from the marketplace team participating in these calls as many extension developers might have questions about best practices for packaging, publishing, tracking, and marketing our extensions to vscode developers and currently there is no open channel for communicating with that team, or even starting discussions on better analytics either built into vscode extensions tab or the marketplace. My 1 request I'd like to see some improvements on in vscode ecosystem and provided tools and api's for extension authors.

As for recording meetings: definitely make those sessions public, including chat text transcript & I do like the idea of keeping low number of presenters and activists to discuss subjects of their expertise, yet allow others to join in listen/chat comments only mode.

[eamodio]

We posted the details about the March extension authors call -- #93604

Don't forget to sign-up to participate! Looking forward this!

[eamodio]

Closing this as we have kicked of this proposal now -- thank you for all your feedback!