Local polls in Issues

[Scharunge]

• Gitea version (or commit ref):
• Git version: 1.9.2
• Operating system: Windows
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite

Description

Feature Request

There is a posibility to create polls via https://app.gh-polls.com/ which is a great thing. Apparently I can't use this soulution due to company policy. Its not allowed to store information of any kind on external resources.

It would be nice if I could create a poll directly in a gitea issue.

[domi41]

It would be nice if I could create a poll directly in a gitea issue.

We're experimenting (day 1) with Go and Gitea and trying to rank issues (quality?, urgency, importance) using Majority judgment (MJ). It would be nice to cover the case of "inline", markdown-created polls too. How do you envision setting it up in markdown? goldmark looks quite extensible.

Since we're absolute beginners both in Go and Gitea, enlightened supervision and guidance would not go amiss.

So far we see the following new models:

• Poll
• Vote (Judgment)

[shubham8agar]

This will be great to add such feature/enhancement in issues. This will help collaborators to make judgement over a issue which require opinions from multiple people.

[domi41]

Our PoC works and integrates quite nicely with Gitea. Example:

I've had to pause dev, though, because I needed to pay rent and I could not find funding for this. Would love to keep at it, especially with the liquid (delegative) features, since we have some (theoretical) algorithms that look quite nice.

[shubham8agar]

Our PoC works and integrates quite nicely with Gite

Is this opensource ? Can u share link ?

[domi41]

Is this opensource ? Can u share link ?

Technically, yes.
It's on a Gitea instance that has been overrun by bots, although we closed registration after the first few bots ; no idea how they did it.

Thankfully, I had forked on Github as well here : https://github.com/domi41/gitea/tree/mj-v1.14.3 and https://github.com/domi41/gitea/tree/mj-v1.18.3 (latest)

State of things

• Needs integration as a plugin, but at the time it was not possible I believe, as I had to add new routes and models, and hook templates in some odd places.

• Needs update to the latest Gitea version. (it always does)

• The MJ (Majority Judgment) algorithm is quite efficient and should scale very well.

• But since then it has been refactored in a standalone Golang Majority Judgment library, to be used by another software piece, the Golang CLI tool to solve MJ.

[domi41]

@shubham8agar I rebased the thing on Gitea 1.18.3, in this branch : https://github.com/domi41/gitea/tree/mj-v1.18.3

I'm still unsure how we could write this as a plugin.
Do send me MRs if you make improvements :)

[luwol03]

Why should this be a plugin?

[domi41]

Why should this be a plugin?

This is actually a very good question.
I can fathom a few motives :

1. Easier installation into existing Gitea instances (no merge, only file additions)
2. Easier maintenance during Gitea upgrade
3. Easier maintenance of the Poll component itself

Someone asked me why I did not make a PR ; this is a simple proof of concept, and, besides requiring approval, integrating this further into Gitea would require some careful work in the various Administration panels, up to the INI configuration file to enable and configure things, and I"m not intimate enough with Gitea yet to undertake this right now.

Right now I'm trying to squash commits to make cherry-picking easier. Awkward.

So let me ask : what do you think it should be, if not a plugin ?

[luwol03]

So let me ask : what do you think it should be, if not a plugin ?

Directly integrated into gitea core? I understand that you are not so familiar with the gitea codebase. But I am curious if there is another argument against integrating it directly.

[domi41]

I am curious if there is another argument against integrating it directly

If there is, it won't come from me. :)
I desperately want a solid polling system.

Perhaps we should aim to consort on specs before undertaking the endeavor of deep Gitea integration ?

So far we have:

• Feature F01: Create a Poll in a Repository with Issues (& MRs) as Candidates
• Rule R01: Creating a Poll (F01) requires Repository Ownership
• Feature F02: Vote on / Judge an Issue in an open Poll
• Rule R02: Voting (F02) requires write access to the Issues

I want :

• Rule R03: Creating a Poll (F1) requires a specific Permission
• Feature F01-01: Configure the Grading set of a Poll (F01)
• Feature F01-02: Target specific Issues & MRs for a Poll (F01) (done in mj-develop)
• Feature F01-03: Set a lifetime to a Poll (F01)
• Feature F03: Enable/Disable Polls for all Repositories (done in mj-develop)
• Rule R04: Enabling Polls for all Repositories requires being Admin (done in mj-develop)
• Feature F04: Enable/Disable Polls for a Repository (done in mj-develop)
• Rule R05: Enabling Polls for a Repository requires being Owner (done in mj-develop)
• …

The rationale behind starting with Issues as Candidates

• Easier initial integration (at least to me)
• We get comments, tags, all the collective discourse goodies on each Candidate
• It's nice to rank issues by Enthousiasm or (Expected) Difficulty, Urgency, etc.
• We can still make any poll we want, albeit it's a little tedious to add issues for each candidate, but that can be helped.

The problems I face

Inline polls that anyone can start in a comment would be amazing.

With all the strict typing going on, I'm not sure how to write things so they'll work for both kinds of candidates (Issues, and Inline). If you understand what I mean and know what I should read/know to solve this, please bring your lights 🌟 .

[domi41]

A little teaser… :) I really like how wonderfully things click into place with the units. Gitea is really nice.

To proceed further:

• figure out the duality of Candidates (Issues or Inline)
• refactor to use the external judgment module
• …which will enable gradation and color poll settings
• allow targeting a subset of Issues

[domi41]

I updated the Polls fork to Gitea 1.20.5, and improved the general friendliness of the Badge Polls.

---

A few tweaks aside, my general next step is to work on the Inline Polls that are the actual ask of this Issue. If you have features, specs, must-haves, and so forth, now is the time to make them known.

---

Note: at the time of this post, mj-develop is outdated. I will resume working on it eventually, as it is based on main.

[domi41]

I've updated mj-develop with some changes, polishing the badge poll feature a little bit, while experimenting refactoring for inline polls.

We can now choose amongst multiple available gradings (formerly gradations), as you can see in the screenshot above, using animals instead of emotes.