Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Count 馃憤 of the team #39

Open
mysticatea opened this issue Nov 11, 2017 · 6 comments
Open

Proposal: Count 馃憤 of the team #39

mysticatea opened this issue Nov 11, 2017 · 6 comments

Comments

@mysticatea
Copy link
Member

Though I'm not sure that it's possible.

As our guideline, accepting enhancement requires a champion and three or more 馃憤s.
But it's not easy to know the issue status because everyone can put 馃憤 icon.

So I think convenience if the bot adds labels which show the issue status.

  1. About feature or enhancement issue.
  2. The bot counts the number of 馃憤 of the team members, then the bot adds a label: 1-supported, 2-supported, 3-supported or something like.
  3. The bot adds accepted label if there is an assignee and 3-supported.

How do you think?

@platinumazure
Copy link
Member

One caveat: Core enhancements/features are not subject to the champion+3 rule; they always should be approved by TSC. I think it would be safest to require "rule" label as well as "enhancement"/"feature".

That said, I would definitely find something like this useful, if we could either minimize noise from the bot or be very intentional about the noise.

A "noisier" approach that could nevertheless provide some value is for the bot to actually leave a post which shows current team 馃憤 and champion and also briefly explains the Champion/Consensus processes (with links for more details). That would possibly help reduce questions about the process.

@platinumazure
Copy link
Member

platinumazure commented Dec 8, 2017

I'll take a look at this, if nobody has any objections. I think the approach I'll probably use in my prototype will be that the bot will create a reply comment right away saying something like,

Hi (issue creator), thanks for the (new rule|rule change) proposal. Rule proposals are accepted when the ESLint team reaches consensus (insert link here).

Champion: (N/A)

馃憤's: (N/A)

馃憥's: (N/A)

And the bot would edit this comment as reactions come in to the main issue. If we get to a champion and three 馃憤's with no 馃憥's, it could also remove "evaluating" label and add "accepted" label.

Of course, we could also do away with the comment and just have the bot focus on the labels, but I think a friendly response could still add value.

If anyone can think of an approach that's obviously better, please feel free to throw it out, but otherwise I think it's worth at least getting the bot logic written-- exactly how the bot chooses to output results is something we can tweak pretty easily.

@mysticatea
Copy link
Member Author

Thank you so much!!

I agree with you, the friendly response is better.
Additionally, I'm gladder if it's easy to search by the issue status. It was the reason that I proposed to use labels at that time.

@platinumazure
Copy link
Member

I've got a local WIP branch for this (not yet pushed to GitHub).

One of the biggest challenges here is that there is no web hook for reactions, unless it counts as an issue edit (which I doubt since the reactions aren't in the issue payload). There is a set of reaction APIs (although those are in preview), so we can at least get the reaction info at key times (e.g., issue is assigned or unassigned, which could mean a champion or removal of champion). But we might need to rely on probot-scheduler or similar to iterate over all issues/PRs and calculate the consensus status once in a while.

At some point, I'll push my local branch so people can see what I have in mind so far. But it will definitely be work in progress.

@platinumazure
Copy link
Member

Apologies, haven't had a chance to work on this. The lack of web hook for reactions makes this a lot harder than it would be otherwise. If someone else wants to give this a shot, feel free.

@platinumazure
Copy link
Member

This might no longer be necessary due to https://github.com/mysticatea/eslint-evaluating-issues (thanks @mysticatea for putting that together!).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants