Prioritize Issues / Feature Requests Based On Voting System


Continued from a slack conversation:


I would really like a system for ranking Atom issues by popularity, this would ensure that the biggest issues are noticed first

Every small part of Atom core can be improved (in some way big or small), across many repositories, which makes this process of figuring out where to put our time excruciating when the only ways to shed more light on issues is through perhaps reactions or bumps.


Many of the popular issues have the help-wanted tag attached to them, so you can try searching for that. Alternatively just sort by Most commented (which is what I do sometimes).

Continued here on discuss:

Well, for example I have a pull request for something that has been discussed on the boards, and it is a very common feature for editors, but it is a small change that may not receive much if any attention while everyone is so busy. Just looking at other core packages, important or frustrating features don’t have a great way of distiguishing themselves


Part of the reason why a voting system doesn’t exist for Atom Issues is because the Atom team isn’t going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. Sometimes we are going to choose to implement or not implement what we feel we have the resources to support, not what people would want us to have the resources to support. Sometimes we have to make some tough choices and not accept pull requests because they don’t have enough tests or they add features that are confusing for people even if they are really useful for a minority. Sometimes we have to refuse pull requests because we feel they don’t make sense to us in certain packages as we envision those packages.

We don’t have a voting system because we don’t want to implicitly set an expectation that “if you can drum up enough votes for this, it’ll be in the next release” … because that is not guaranteed to be true.

Now, what I can offer and pledge to do every single day (except for the occasional day that I take off) is that it is my job to listen to the community. It is my job to bring the thoughts and concerns and desires and ideas of the community to the Atom team. It is my job to do my best to represent the community in every meeting, every planning session and every design decision. And it is my job to make them listen. (I should change my username to Tron.)

Also, I’m working on some ideas I have to make the important things more visible and easier for me to distill and represent to the Atom team. Of course, that’s in between all the time that I spend reading, responding, helping and representing already. So sometimes it is slower going than I want. But I feel it is also going to be better than a voting system because it is going to cover more heuristics than “X people clicked a button”.

I appreciate your enthusiasm and your feedback, @ZombieHippie. I hope you can understand and respect how we feel about the situation too.


Thank you for your detailed response, I certainly did not intend to undermine the current processes.

I also do not believe the majority should rule, as I can not be certain that my change is particularly useful more than harmful (to users, to maintainability, etc)

I hope the best things are prioritized, and the people who put in their work to submit pull requests are met with feedback earlier than later.

Does GitHub have an issues moderator feature? Haha!


No, but we have a triage team (consisting almost completely of trusted volunteers) that combs through everything that is submitted and every comment posted as best we can. They make sure I see things that I might have missed, close duplicates, answer questions and generally help out in a myriad of ways. So if that is what you meant by an “issues moderator”, I guess, yes, we’ve built one for ourselves :grinning:


+1 vote here to “Issues vote” :wink:

@ZombieHippie and @leedohm, allow me a conceptual review?

The main purpuse here is perhaps

a system for ranking Atom issues by popularity (…) biggest issues are noticed first

so, it is a mistake to suppose that it is a kind of “exercise of rights” (!), it is only a statistical and communication facility. More persons lost less time using voting system, than using comments – and reinforces objective topics, leting details to later, when (and if) the topic was accepted.

There are two very distinct communities:

  • the user community, that in this place is like a stakeholder body.
    … It is not a formal body, only the sum of individual perceptions, but can gain some “collective existence” by organization and dynamics.

  • Atom team (perhaps development community + “GitHub, Inc.”), that is the “all rights” holder; but need to listen (only to listen) to the user community.
    The Atom team is a formal body, and the holder of all project’s decisions (issues organization and decisions)

  • (NOTE) “global Atom community” as a kind of “user community + Atom team”, not exists (at this moment it is a “wispy body”).

So, it is important to look the vote as an user community voting system, to turn its communication more simple, effective and transparent… The community want only to say, as a collective: “look, after discussing this topic with pluralist participation, we can summarize our preferences by this voting result”.

Other point.

There are near ~2 thousand issues, and a lot of issue-discussions here, all public and oriented to “listen to the user community”… Would be more effective to manage all this “listen stuff” with some feedback statistics, by a vote system.


+1 I completely agree with @Krauss and @ZombieHippie