Voting a Feature Request Before Create Work #9899

New Issue

GiteaMirror · 2025-11-02T08:52:36-06:00

GiteaMirror commented

2025-11-02 08:52:36 -06:00

Originally created by @ghost on GitHub (Nov 28, 2022).

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

Some practice:

Originally created by @ghost on GitHub (Nov 28, 2022). 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 - https://github.com/microsoft/vscode/issues/162138

GiteaMirror added the type/proposal type/summary labels 2025-11-02 08:52:36 -06:00

GiteaMirror closed this issue

2025-11-02 08:52:37 -06:00

GiteaMirror commented

2025-11-02 08:52:38 -06:00

@lafriks commented on GitHub (Nov 28, 2022):

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

@lafriks commented on GitHub (Nov 28, 2022): 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

GiteaMirror commented

2025-11-02 08:52:38 -06:00

@delvh commented on GitHub (Nov 28, 2022):

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 😅 )

@delvh commented on GitHub (Nov 28, 2022): 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 :sweat_smile: )

GiteaMirror commented

2025-11-02 08:52:38 -06:00

@lafriks commented on GitHub (Nov 28, 2022):

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.

@lafriks commented on GitHub (Nov 28, 2022): 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.

GiteaMirror commented

2025-11-02 08:52:38 -06:00

@ghost commented on GitHub (Nov 28, 2022):

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

This issue will be closed later :)

@ghost commented on GitHub (Nov 28, 2022): Thanks for your comments. I have seen the disadvantages of this suggestion. This issue will be closed later :)

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#9899