Voting a Feature Request Before Create Work

[ghost]

My suggested workflow is
Feature Requests -> up-voting 20 -> Backlog -> Milestone -> Work on it -> PR -> Merge

Some practice:

• https://github.com/microsoft/vscode/wiki/Issues-Triaging#managing-feature-requests
• Feature request: Git branch history microsoft/vscode#162138

[lafriks]

I think there should be no problems to implement this as external tool using gitea webhooks listening on issue changes and adding to backlog using board API

[delvh]

Except I don't think the 20 upvotes is feasible for Gitea.
That might work for a client-side application like VS Code with a much larger audience where users are likely to look through issues and upvote them.
But in general, people mostly expect server-side apps to just work, where they only file issues if they have an issue themselves and or if they have an actual idea what to propose.
From what I've seen so far if we do that, only the enormously big issues such as CI (#13539) and federation (#18240) will be merged.
Not even the plugin system (#20126) or "GitHubs useful functionality" (#8659) would then be implemented since they don't get enough likes.
I don't think we can afford to do that.

---

Apart from what I mentioned above, I can certainly see this being useful (with the only problem that we don't have a clear roadmap yet 😅 )

[lafriks]

If that is meant for using in Gitea development process I don't see much point in that as there won't be much point in voted backlog if anyway noone volunteers to implement that... I think most contributors implement what they find interesting or need themselves not based on request popularity.

[ghost]

Thanks for your comments. I have seen the disadvantages of this suggestion.

This issue will be closed later :)