Meta Feedback (feedback about feedback)

[MylesBorins]

Hey All,

So this feedback process is pretty new and there are bound to be thoughts about how it is currently implemented and suggestions about how to do better. Please leave you general feedback in this discussion.

[mikesherov]

As a curious consumer of the npm public roadmap, I really appreciate this visibility. It's a nice step forward. However, I'm mostly interested in the changes to the tool I use daily, which is the CLI (and by extension, the registry). While the website is indeed vital and important work, it's just not part of my day to day the way the registry and CLI are.

As such, when I visit the project page, seeing all 3 areas of development on a single roadmap muddies clarity slightly. While I can always filter the roadmap by labels, what y'all decide to group together as projects says something. Maybe it's to say all of these areas of concern are of equal interest and importance. Maybe it's to say "this is 'just' everything we're doing, filter what you'd like". Separately, I haven't yet figured out how to show both cli and registry in 1 view using filters... maybe by "github query filtering language" abilities are not good enough 🤷

[MylesBorins]

Hey @mikesherov,

The intent here is to show the entirety of work our team is focused on.. which includes all of our products. Part of the hope is that we can use to to be transparent about our priorities, especially in the case where we say we can't prioritize something.

There are work items that could easily span all three products, such as what is being discussed in https://github.com/npm/feedback/discussions/13

With that in mind I think it makes the most sense to keep all of the products on a single roadmap. It is unfortunate that GitHub's filters don't allow for "OR"... I can follow up with that internally.

[MylesBorins]

Exciting news! I found a query that should work for you. While you can't do OR you can do NAND!

https://github.com/npm/roadmap/projects/1?card_filter_query=-label%3Awebsite+-label%3Ameta

[Ethan-Arrowood]

Are there other npm feedback channels/forums/boards that I could search around on to make sure my feedback hasn't already been asked/answered? I've noticed some people have pointed to npm/rfcs.

[MylesBorins]

The npm/rfcs repo is the only other repo... which is primarily about making proposals from changes to the CLI.

In general we are imagining that the roadmap serves as a lighter touch way to make suggestions. Our team can help triage those suggestions and make sure they get in front of the appropriate folks to make a decision. In some cases that may result in opening an RFC to get a feature adopted in the CLI.

[wesleytodd]

My main take on this new "discussions" feature: it is so hard to follow. The text is tight, the lines are long, the nesting is rough for readability. I spent about an hour reading through the new ones of these tonight, and my brain hurts from jumping back and forth in the threads.

[MylesBorins]

/cc @becca who is a pm on discussions and is working directly with the designers on this new experience.

One thing I've noticed myself is that some folks don't realize that each discussion thread can be independently responded too, and end up starting a new thread as a response to another thread... which gets confusing and verbose.

I personally have enjoyed the separate thread model, as compared to issues, as various conversations can happen at the same time without interrupting each other.

[diminutivesloop]

What's the relationship between the discussions here and the issue tracker on the npm/cli repo?

[MylesBorins]

Discussions is for bringing us suggestions and new ideas.

the npm CLI issue tracker is for bugs.

[trevyn]

I came here via npm/roadmap#12 , "meta: public roadmap and user feedback public beta"

At the bottom of that page, it says "we are live!" and then in bright yellow "An owner of this repository has limited the ability to comment to users that are collaborators on this repository."

So the thread on user feedback is dead-ending at a message saying "you can't give feedback."

I understand the need to lock issues to keep them focused on bug reports, and I applaud using discussions as a method of feedback.

And that "locked and we don't want to hear from you anymore" can easily be read as very hostile and user-unfriendly.

Perhaps make the wording friendlier and require a link to the discussions where people can discuss?

Many other repositories (cough VSCode) have a heavy hand on the lock button as well, bubbling this up to GitHub/Microsoft would be nice too.

[MylesBorins]

Hey @trevyn.

From the roadmap README.md

Issues will be created for features and work items we are tracking on our roadmap. Issues are read-only and locked on creation. Our roadmap is heavily influenced by discussions with our community that take place in our public feedback repository.

The idea is that the roadmap is a place where people can see the progress of our work and what items are being worked on and this discussion forum is where folks can bring feedback.

Is there another way you think we could make this clearer to people?

[MylesBorins]

Also worth mentioning... that specific ticket was tracking launching this feedback forum

[trevyn]

I’m coming from the open source ecosystem, where GitHub issues are generally used for bug reporting and feature requests, comments are open to anyone, and are generally only locked if there is an obvious amount of drama. Users are expected and encouraged to give productive feedback anywhere it makes sense, including in issues.

So any repo that uses issues in a different way immediately has a learning curve. That’s fine!

And it sounds like your overall goal is to increase engagement and trust with the community. That’s great!

My point is that there is a community norm that feedback is not just tolerated, it is valued, and effort is made to make the feedback process easy, natural, and relatively consistent across repos, so the whole ecosystem can benefit from a similar flow no matter what repo you’re in.

If you decide to experiment with new repo structures to make feedback more manageable, that is wonderful. My point is that because it conflicts with the expectation, the messaging around how the issues feature is used needs to be very clear, and preferably in the exact spot on the page where users are expecting to provide feedback.

i think a great solution would be to provide a customizable per-repo string that goes in the “this issue has been locked” yellow box explaining where to give feedback, preferably including a direct link, and make the wording as friendly and positive as you can muster. :)