When someone or some people claim(s) a task at first and when everyone abandons the task, the corresponding area label team should be mentioned of the open issue with no assignees.

Currently, issues that have been inactive in the comments for 7 days but have an open PR referenced are being flagged as inactive. This shouldn't happen.

It always a good idea to set up a linter for code readability and quality, since this repository doesn't has a linter yet, so I'd recommend to set up it.

I'd recommend eslint for this repo, since it supports ES6 and works with some framework like CommonJS, and easy to configure. Any thoughts for this? like rules for the linter, or recommend another linter.

When PRs/issues are labelled, zulipbot often leaves a comment concerning the status of the labeling, such as when invalid labels are added/removed (addLabels.js + removeLabels.js) and when area labels are added (issueAreaLabeled.js). zulipbot should check whether it is commenting on an issue or pull request.

(Description added by @synicalsyntax)

When new contributors create new issues, they usually don't label their issues appropriately even though they can do so through the @zulipbot label command.

A new feature can be developed that scrapes unlabeled issues in the repository and remind the issue creator to label them if they're still unlabeled one hour after their creation.

Maybe once #56 is implemented we could suggest possible labels that the issue creator could add to the issue depending on the contents of the issue?

test!

There should probably be a way to remove labels also, now that we have a way to add labels.

Fun fact: zulipbot is deployed on the https://zulip.org/zulipbot/ page.

When you visit it, you get redirected to this repository (relevant lines 18-20 in src/index.js). It'd be nice to set up a website to introduce zulipbot and its features as well as link back to this repository, which would make contributions to zulipbot more welcoming, I think.

Thoughts?

To claim an issue on the repository, comment "@zulipbot claim-issue" on
the issue you want to claim, and @zulipbot will add the "in progress"
label and assign you as an assignee to the issue

For claimed/in progress issues that have been inactive (no comments, no pull requests referenced, etc.) for a week, @zulipbot should ask the assignee whether they are still working on it.

If the assignee doesn't respond with "Yes I'm still working on it" or something similar within a time limit of the prompt, zulipbot remove the assignee and in progress label from the issue to allow other people to work on it.

mockPayload doesn't seem to work currently. Tried doing something simple like @zulipbot claim and didn't work.

@zulipbot label "bug"

We should get rid of duplicate things and create functions for them, especially the following:

• create comment function
• authentication (??)
• getting issue labels

For the future:

• getting labels in a repo
• remove label function (we can actually just use replace label function)
• add label function

Feedback would be nice and any other suggestions for duplicate functions. The one that should be taken care of is a comment function.

When an area label is added to an issue, the corresponding team should be mentioned and notified by zulipbot

I have a feeling that we aren't iterating over all the pages of issues, thus, missing old issues like #3945, which should be labeled inactive.

When zulipbot is mentioned @zulipbot travis, mention PR creator with pass/fail of Travis tests.

More details here.

Testing automatically giving read-only collaborator access to those who want to claim an issue but aren't marked as collaborators.

If you try to reference a zulipbot function in a code block, zulipbot will execute the command; we should disable this for anyone trying to only reference a zulipbot command.

Ex: Use @zulipbot claim to claim an issue

This can be pretty simple. Check capitalization after a colon, or make sure commit message starts with a colon. Related to #51 (this is a meta-issue).

The guidelines can be found here.

We should take the content after the zulipbot mention, otherwise you get the problem in this issue. We don't want to check ALL the content for double quotes, just things after the mention.

Pull requests that contain "[WIP]" in their titles should not reference area label teams until the "[WIP]" status is removed from the title.

(Description added by @synicalsyntax)

Currently a lot of settings for zulipbot are hardcoded, ranging from comment escaping to the inactivity times to the area labels.

Since @brainwane is presenting about zulipbot in about a week, I think it'd be great if we could make zulipbot more customizable in case others want to use their own copy of zulipbot to collaborate on their repositories. To make this possible, we would need to refactor the code to make configuration options for enabling/disabling all zulipbot features and some other settings like area labels/inactivity times.

Currently supported options (updated 3/17)

• Username
• Password
• Area labels & teams
• Inactive issue/PR time limit
• Abandon issue time limit
• Travis webhook notifications (for finished build statuses)
• Travis updates label name
• Self-labeling (only issue/PR authors can manage their issue/PR labels with @zulipbot label & @zulipbot remove
• Inactivity check timeout (how often zulipbot checks for inactive issues/PRs)
• Enable/disable adding in progress label to claimed issues
• Custom in progress label name
• Enable/disable inactive issue/PR tracking
• Repository access when collaborator is added (pull, push, write, etc.)
• Comment templates
• Enable/disable PR "review"/"needs review" system
• Label names of PR "review"/"needs review" system

If you write a comment on a PR that references an issue in area X, zulipbot adds a message to the PR saying "hey folks in area X, check it out", which is great.
If you add another comment that references a different issue in area X, it would be great if zulipbot did not add another "hey folks in area X, check it out" message.
zulip/zulip#3946 is an example of where this happened.

• After a review is made, mark a PR with the "reviewed" label. zulipbot should periodically scrape repos for PRs with the "reviewed" label and remind PR creator that they should update their PR after a certain time.

• Issues that haven't received any reviews should have a "needs review" label.

• After a certain period of time PRs labeled "needs review" should mention the PR reviewers (assignees)

More details here.

Description edited by @synicalsyntax

Mention the corresponding area label team and label PR with area label when PR mentions another issue.

• Check body for newly created pull request
• Check body for pull request (issue) comment
• Check body for pull request review
• Check body for pull request review comment

Issues with multiple assignees should not have the "in progress" label removed when one assignee abandons the issue.

(description added by @synicalsyntax)

zulipbot should check if when a PR references an issue, the PR commit should reference the issue and not only the PR description.

@zulipbot label "new feature" "enhancement"

Check PR #2172.

We should be able to unclaim a task if we accidentally do it.

Description

If you claim an issue with @zulipbot claim for the first time, you are automatically subscribed to the repo (i.e. you start watching it). Therefore, you receive email notifications for everything that happens in the repo, which is a bit annoying, and might be slightly intimidating for new contributors.

Additional information

The hypothesis here is that being added as a contributor implies becoming a watcher for that repo.

A temporary workaround for this could be adding a message with a link to remove the subscription (e.g. https://github.com/zulip/zulip/subscription), but it'd be great if we could directly avoid this. Maybe it can be done when calling GitHub's API?

Fix this line: https://github.com/zulip/zulipbot/blob/master/src/issues/newComment.js#L11

Should only replace "issue" with "pull request" when a pull request is referenced.

We don't want to add labels that have not existed before in the organization. See this issue. There should be a way to filter these labels out.

zulipbot should check issue references in:

• pull request commit descriptions
• edited pull request descriptions (should make sure it wasn't there first)
• edited issue comments (should make sure it wasn't there first)

Note: GH API does not work consistently for Edit events, see conversation below

(title and description edited by @synicalsyntax)

For example, @zulipbot claim.

The following command will not work when it should.
@zulipbot label "bug"

ZulipBot should be able to recommend a similar label / list of labels if the label given by user is not found to be existing.

@zulipbot label "new feature" "enhancement"

When you mention @zulipbot label "enhancement" and @zulipbot remove "enhancement" in the same comment, you should only do the first action, which is labeling and not removing.

Currently, nothing removes the "in progress" label for issues that are closed or resolved.

I think we agreed to use "zulipbot" all lowercase instead of "Zulipbot". We should probably change all the spellings to match "zulipbot" now.

Example: @zulipbot label "@zulipbot claim".

When someone claims a task, the "help wanted" label should be removed (first check if it even exists). However, when someone abandons an issue, we should consider adding the "help wanted" label... Need feedback on this.

When you have something like below:

@zulipbot label "invalid"
@zulipbot label "enhancement"
@zulipbot label "bug"

It labels "bug" first, which is super unintuitive. We should fix this.

issueReferenced and issueAreaLabeled all post multiple comments when triggered, which might be annoying for the area label teams mentioned as well as the issue creator; like joinLabelTeam, addLabels, and removeLabels, we can easily concatenate the related area labels into strings instead of printing one comment for every element in the array.

• issueReferenced
• issueAreaLabeled

@zulipbot claim

I was unassigned from an issue and didn't notice until I couldn't find it in my TODO list. There should be some type of mention from zulipbot that you got unassigned.

New contributors that try to claim an issue receive a welcome message and the issue is labeled as "in progress", but the new contributors aren't actually being assigned to the issue.

Adding a label through a comment. Then adding the same label through another comment shouldn't make the bot add the label again.

@zulipbot claim, @zulipbot label "enhancement"

An example is shown below.

The following issues in the zulip/zulip repository have all received the inactivity comment and have not received an update response, but zulipbot has yet to remove the "in progress" label and the assignee from each issue.

Very likely a calculation error in src/issues/checkInactivity.js.

We could set up at least a continuous integration for this repository like Travis-CI that runs linters, unit tests, etc.