They had a nice system where each developer gets 10 votes and can vote for ideas (or even create a new idea and award it votes). One is allowed to spend multiple votes on a single idea. Switching votes is okay.
It worked very well as a way of probing the weak points of the technology.
I wonder if there is any way of doing something like this with Discourse.
We could create a thread (& pin it) and every idea could be a post and everyone could use the ‘like’ button. Not perfect because some ideas would generate replies & it will get a bit messy. Also one has infinite 'like’s.
But it might be useful. I notice conversations on Github going along the lines of “We are very surprised to see so many developers like e.g. x and y over x && y!”. Some kind of feature voting system might reduce surprise in certain situations.
There is in fact a Discourse plugin for this feature: https://meta.discourse.org/t/discourse-feature-voting/40121. Could be worth a shot. I tried it on the Juno forum (which seems like a good candidate for this kind of feature) and it works well technically, but it didn’t get a huge amount of usage.
I just read up on that plug-in. It is designed to record and display “vote” occurrences. At the topic level, one may choose to vote or refrain from voting +1 for a topic. There is no way to have a topic like “renaming the type keyword” and vote a preference for alternative (a). That would be useful.
I would be interested in seeing user votes as an informative signal, but keep in mind that it wouldn’t be binding in any way. It’s always good to know what the major pain points and problems people are having are. We should also remember that people who read and participate on this forum are not representative of all Julia users – the typical Julia user has never posted on any Julia forum.
As someone who uses Unity3D quite a lot I have to say I really appreciate the feature. I don’t think it is (or should be) binding, but to me as a user this feature always felt very positive to me regardless. It gives me the impression of being in the know without having to weave through pages of issue discussions on a regular basis. It also gives me a sense of community and participation without the angst of annoying people with experiences or concerns that have been heard before one way or the other. I do quite regularly come across some issue or idea that I like but am a bit reluctant to post a non-informative message such as “I would like that as well!” all the time. The little “like” buttons on github don’t feel that useful on messages that aren’t brand new.
I think this is the key. It’s hard to “prioritize” when most users aren’t helping develop, and those who are developing mostly are volunteering of time and expertise (except for a few core developers). Too visible of a voting system can make it look like “developers” aren’t responsive, but not only that, it makes it seem like there is a division between “developer” and “user”. In reality, if you want new parallel functions, you shouldn’t upvote for it: you should build a library or start asking for help in implementing it.
The other thing is that you have to give some benefit of the doubt to the developer. Developers know what needs to be done. Jeff, Stefan, Tim, etc. don’t need votes to know that we want traits, and we want conditional modules, and we want a solution to #265, etc. They need more hands and more time!
Also, If some design decision seems dumb to a user, there’d be more of a tendency to “want to vote it away” rather than trying to understand why it’s there in the first place. For something less complex (and paid for) like an email application I can see a vote making sense (it works well with Mailbird). However, with something as complex as a programming language, I think there’d be a lot of people who will vote for “feature enhancements” like “multiple inheritance” without trying to come up with an implementation, when really it’s the implementation that would be the entire issue (and judging from Jeff’s thesis, I think it would be impossible to do and still have all of the type inference?).
Because of this, I don’t think that votes will or even should guide the development. I think this kind of stuff may become “evidence” that the developers aren’t responsive to the community (of course, this is pure speculation), when in reality the idea of “the developers” being “responsive” doesn’t really work in this case. A lot of the contributors (500+!) are contributing code to the issues and enhancements that help their work, and a few votes won’t magically change someone who’s contributing code to improving parallelism to be someone who is working on a type inference problem (only running into the type inference problem in their own work will do that!).
There is an alternative where you can use money to get developers working towards your priorities. If you are some company, really want/need something to be prioritized by people who are very familiar with Julia development, and are willing to pay for it: isn’t that what getting in contact with Julia Computing is for?
One striking difference between C++ and Python is that one is designed by a committee, the other by a benevolent dictator. And it really shows! Python is so elegant that the term ‘Pythonic’ has emerged to describe a kind of zen perfection in coding style.
Democracy is no fit environment for a programming language – a meritocracy is the only way! And the merit is with the creators.
However, Julia will appeal to a wide variety of users and most developers will be coloured by their own particular direction/niche. So as it grows some kind of feedback system may be helpful in keeping the overall ecosystem in proportion.
I don’t think a voting system could really cause any damage. It will bubble up issues that aggravate people. It would act as a kind of ‘ideas tracker’. As pointed out, it would provide a place for people to feel they have been heard without having to dilute some thread with a ‘me too!’. It is simply providing more information. It might cause some antagonism between users/devs but to be sure it is impossible to please everyone!