Is there a way to do category-based vote limits? I would like to have feature requests category with only few votes, but then also a bug tracking category with limitless votes so that a vote would mean “i experienced this”.
Or would like/hearts be the better way for latter? It just feels wrong to like a bug…
I’m testing out the voting plugin right now and I think this feature would be a good fit for our use case. Would be grateful for advice and ideas. Thanks!
We are considering using this plugin to allow the community to vote for representatives to join our network guidance committee. There might be more than one opening at a time with up to 6 candidates vying for the same opening. My thinking is that we’d have a VOTING category with voting plugin enabled sub-categories for each opening. Within each opening category there would be one topic per candidate, authored by the candidate, containing their message introducing themselves and why they should be elected. All site members would be allowed just one vote for each candidate.
So the current model that gives each user a set number of votes they can “spend” however they like doesn’t work. We’d have to provide enough votes for each user to be able to vote for all candidates, but do not want to have them spend them all on the same candidate.
For those who might be curious, here's the full election process as we are considering it right now.
NGC members serve for 3 year, renewable terms. A vacancy arises when an NGC member decides not to renew their NGC membership for another term. Filling the vacancy will be based on universal criteria applying to all NGC members as well as specific criteria to round out the committee (e.g. gender of candidate or by region, theme, type of organization represented).
On April 1st of each year, announce vacancies for nominations.
This call for nominations will be open for two months until June 1st.
Candidates, whether by nomination or self-nomination, must submit a resume and cover letter stating their intent to be on the NGC.
All who submit appropriate documentation are called “nominees”.
A selection committee made up of network team members and NGC members reviews the resumes and documentation of nominees. The selection committee will decide which nominees clearly do not meet minimal qualifications and eliminate those nominees. This requires a unanimous agreement by all members of the selection committee.
Those nominees who meet the minimal qualifications will be contacted by a member of the selection committee for screening.
By August 1st, the selection committee will select no more than 6 people for each vacancy to be considered for election. These selected individuals will be called “candidates”. The selection process will be done by consensus. If consensus cannot be achieved, then the chair of the selection committee may call for a simple majority vote on any nominee becoming a candidate with the chair of the committee having the deciding vote.
Two months later, on October 1st, the results of the election are announced and the retired NGC members are removed and the new NGC members are added to the NGC page and discourse group.
A simpler alternative may be to create poll topics for each opening, and add the “pitch” text and maybe a photo for each candidate to the OP. But it seemed interesting to create some healthy and fun competition by having multiple topics that people can vote on.
I just made a PR that implements category based vote limits. Category based limits can be set for each trust level for each category. Category limits override ‘site’ limits.
@tobiaseigen Actually, you may be interested in the elections plugin I just completed. It fits your use case quite well. It extends the concept of having one poll per topic. I built it for my own purposes (i.e. I’m going to be actively using it), so I’m keen on ironing out any issues it may have / getting the feature set right.
hey everyone! I’m not sure if this is the right thread (but I’ve been perusing around and it seems like it could be) but we are looking to allow for more than one upvote for a topic. Is this something that a plugin (that already exists or is under development) could support?
We experimented with super votes in the past, but it got fiendishly complex to explain to end users. We don’t have any current plans to add super voting or extra voting cause I think the complexity this adds is just too high.
Я хотел бы предложить возможность настройки количества допустимых голосов для каждой категории отдельно. Основной сценарий использования для меня — раздельное голосование за функции и баги, так как я считаю приоритизацию обоих направлений важной, но независимой друг от друга. Я не обязательно хочу давать пользователям, например, 20 голосов, которые они могут потратить исключительно на функции, но считаю, что 10 голосов недостаточно для совокупности функций и багов. Мне интересно, разделяет ли кто-то ещё это мнение и, если нет, как вы решаете вопрос приоритизации багов и функций в контексте этого плагина.
Понимаю, что это, вероятно, довольно масштабная просьба о новой функции для данного плагина, но она могла бы быть весьма полезной (и меня удивляет, что её не запрашивали ранее, хотя, возможно, это связано с автоматическим удалением ответов здесь, поэтому я этого не вижу…). Надеюсь, это предложение будет рассмотрено.
Редакция: теперь, когда моя тема была объединена здесь (извините за дубликат, я искал, но не был до конца уверен, что именно ищу…). Мне просто интересно, что произошло с обсуждением здесь. Кажется, оно немного ушло в сторону, но исходная просьба о новой функции по-прежнему очень полезна, на мой взгляд. Я уже отметил Angus в другой теме, так что надеюсь, он выскажется…
@oshyan Да, это выполнимо, однако я бы хотел полностью переписать этот PR, так как за последние 4 года плагин сильно изменился (неужели прошло уже столько времени?).
В реальности у меня нет времени заняться этим в ближайшие пару месяцев, но поскольку это относительно изолированная задача и подходящий кандидат для PR, её можно выполнить следующими способами:
Участник Pavilion в рамках их работы с открытым исходным кодом для Pavilion (возможно, @fzngagan, @keegan или @kcereru были бы заинтересованы);
Кто-то другой, кто заинтересован в работе с открытым исходным кодом Discourse (если вы, дайте знать, если нужна помощь; @Ahmed_Gagan?);
Если есть бюджет на это, вы можете создать пост в Marketplace, и Pavilion возьмёт это в работу как платный заказ (то есть это будет сделано быстрее / разработчик будет мотивирован); или
Спасибо за подробный ответ! На данный момент у меня нет бюджета на это, но я попробую найти средства.
Если кто-то ещё из участников тоже заинтересован, мы могли бы собрать необходимую сумму вместе. Я готов внести личные средства, но смогу выделить лишь несколько сотен долларов США. Присоединяйтесь, если вы тоже можете сделать то же самое!
В более общем плане мне интересно, видит ли кто-то ещё в этом такую же ценность, как я, и замечает ли ту же дихотомию между голосованием за функции и за ошибки. Активно ли используют голосование официально размещённые форумы? (Я не ожидаю, что они будут названы по имени, скорее просто исследую вопрос о том, насколько это может быть ценно для платных клиентов Discourse)
Да! Мы недавно использовали голосование по темам для награждения призами за постеры на семинаре:
Это отличный пример использования этой функции: голосование можно изолировать только в одной подкатегории, и мы сможем делать то же самое на следующем семинаре, не сбрасывая голоса в предыдущем конкурсе.
Это также позволит проводить голосование по темам в нескольких потоках одновременно.