search

rickstaa / top-issues-action

Labels and displays the top-upvoted (i.e. 👍) issues and pull requests in your repository.
MIT License
20 stars 1 forks source link

Voting system allowing people to prioritize (Multiple points per user upvote) #94

Closed rickstaa closed 1 year ago

rickstaa commented 2 years ago

Is your feature request related to a problem? Please describe.

Issue: Github "voting" system is binary: +1 or not.

We would like to let people express their own preferences. If I think this issue is more important to me than other ones, I would like to claim it.

We have tested the following system to sort the issues: each participant has 100 credits quarterly and he can put them on the issue(s) he wants to. He can put 100 credits on one issue or allocate it on several issues. The drawback of this method is that we need to do it by hand :(

Describe the solution you'd like

I don't know if it's possible to parse Github issues' comments, but we could use a system where people would vote with a simple syntax, something like: #My_credits_for_this_issue: 80 The parser might detect the hashtag and its corresponding amount, the user and the date of the comment. This way, it might be possible to establish a ranking based on people priorities. Do you think it's possible?

I understand that the drawback would be the multiplication of comments but it's already the case in many projects where people are adding "+1" in the comments.

Describe alternatives you've considered

Doing this by hand in a shared spreadsheet.

Additional context

No response

Is your feature request related to a problem? Please describe.

Issue: Github "voting" system is binary: +1 or not.

We would like to let people express their own preferences. If I think this issue is more important to me than other ones, I would like to claim it.

We have tested the following system to sort the issues: each participant has 100 credits quarterly and he can put them on the issue(s) he wants to. He can put 100 credits on one issue or allocate it on several issues. The drawback of this method is that we need to do it by hand :(

Describe the solution you'd like

I don't know if it's possible to parse Github issues' comments, but we could use a system where people would vote with a simple syntax, something like: #My_credits_for_this_issue: 80 The parser might detect the hashtag and its corresponding amount, the user and the date of the comment. This way, it might be possible to establish a ranking based on people priorities. Do you think it's possible?

I understand that the drawback would be the multiplication of comments but it's already the case in many projects where people are adding "+1" in the comments.

Describe alternatives you've considered

Doing this by hand in a shared spreadsheet.

Additional context

No response

Originally posted by @anuraghazra in https://github.com/anuraghazra/github-readme-stats/issues/2193

rickstaa commented 2 years ago

@CharlesNepote Thanks for your feature request. I thought of something similar, and I think what you are asking for is possible since the GraphQL API allows the following:

Unfortunately, implementing such a system as a GitHub action would, I think, not be feasible with the current GraphQL API since this system would scale exponentially with the number of users and issues. This action would, therefore, quickly hit the GraphQL rate limits. A way to deal with this would be to run the action in multiple steps while keeping track of the GraphQL cost. Implementing this logic is complicated and would still be inefficient since old data is fetched on each run.

If I would implement this feature, in the form you suggested, I would likely not use a GitHub action but create a Github application. Doing this would allow me to run a cloud function whenever a user upvotes an issue or only periodically fetch new information. Storing this information in a server database would allow the logic to be run and coded on the server. This setup would allow for a nicer interface to show the most upvoted issues and allow users to assign more points to a given issue.

Nevertheless, I think implementing such an App would be a significant undertaking and only worth it if a lot of people/companies are interested in such an app and if there were no other alternatives. There are already (paid) feature voting apps for more advanced feature tracking use cases that can integrate with GitHub. To name a few:

The reason I created https://github.com/rickstaa/top-issues-action was to have a free, easy to setup way to quickly see issues/feature requests/bugs/PR that were most upvoted. It was meant to be an extension of GitHub's own filtering abilities on the GitHub website.

rickstaa commented 2 years ago

@CharlesNepote Having that said, I might implement a GitHub app version if there is enough interest in this feature from the community. 🚀 Since this action is relatively new currently, it is only used by https://github.com/openfoodfacts and https://github.com/anuraghazra/github-readme-stats.

CharlesNepote commented 2 years ago

Thanks a lot for your answer!

Unfortunately, implementing such a system as a GitHub action would, I think, not be feasible with the current GraphQL API since this system would scale exponentially with the number of users and issues.

Would it be possible to run it only once day or even once a week, to stay below the limits?

rickstaa commented 1 year ago

@CharlesNepote I rechecked your suggestion, and it will cost fewer GraphQL points than I anticipated. The query we need for your idea is as follows:

{
  rateLimit {
    limit
    cost
    remaining
    resetAt
  }
  repository(owner: "anuraghazra", name: "github-readme-stats") {
    issues(first: 100, states: OPEN, orderBy: {field: CREATED_AT, direction: DESC}) {
      nodes {
        number
        title
        positive: reactions(first: 100, content: THUMBS_UP) {
          totalCount
          nodes {
            user {
              login
            }
          }
        }
        negative: reactions(first: 100, content: THUMBS_DOWN) {
          totalCount
          nodes {
            user {
              login
            }
          }
        }
        comments(first: 100) {
          nodes {
            body
            author {
              login
            }
          }
        }
        labels(first: 100, orderBy: {field: CREATED_AT, direction: DESC}) {
          nodes {
            name
          }
        }
      }
      pageInfo {
        endCursor
        hasNextPage
      }
    }
  }
}

This will cost 400 query points per call. We, however, have to paginate through all issues, comments and labels so the total number of points can be higher. For a repo with 500 issues, with each issue with less than 100 comments, reactions, and labels, we need 2000 query points. This is 20 GraphQL points and thus well within the 5000 points limit (see https://docs.github.com/en/graphql/overview/resource-limitations).

The maximum complexity of your idea will be 4*(100*100)+100+2=40102, which is also within limits.

The main thing why I'm hesitant to implement your feature request is that it requires a lot of code to loop through all issues, reactions and comments, making the codebase harder to maintain and read. I, therefore, still think a GitHub APP with a database is a better idea.

I can, however, add a feature that allows you to show the results for a specific period (e.g. last month) 🤔 . Maybe this will improve your workflow (see #111).

rickstaa commented 1 year ago

I suggest we switch to a GitHub App because a GitHub app can be triggered at every reaction that is added. This would allow us to store this information in a database, allowing us to create more complex top issues dashboards like the one you suggested.

rickstaa commented 1 year ago

Closing this as I currently do not have the time to implement a GitHub App version of this action.