hugopl / reviewit Goto Github PK

Problem: An user action that does not give anything valuable.

Possible solutions:

1. Add a simple check to only display this link if we have at least one MR. (easier solution)
2. Implement a counter to display how many MR are pending and closed for each project. If it doesn't have a merge request, make it a plain text instead of a link.

An example(something like that):

• Project A, [5 Pending](link 01) and 0 Closed merge request(s).
• Project B, 0 Pending and [6 Closed](link 02) merge request(s).

Would be nice to choose what kind of emails notifications you want to receive, so you can e.g. be part of a project and don't get flooded by a lot of emails about MRs.

They should be threaded, so we get more organized inboxes.

the linter should receiver absolute paths.

By update I mean the events:

• New comments.
• Change target branch.
• Status become accepted, rejected or needs rebase.

Everyone involved in the MR but the author of the event should get a email.

Add support for emoticons inside comments 😄

UI should show the time when the comment was written.

It should be renamed to IR (Integration Request) or something else... Pull Request also doesn't make sense since it's patch oriented, not branch oriented like github and gitlab.

A rake task to create reviewit gem should exists.

It should work like the cancel command, display the MR title and ask for confirmation.

Just like phabricator does.

Sometimes the inline diff is confusing. Showing the previous version besides the new one can make things clearer.
Both options should sits in tabbars to easily change between them without reloading the page.

Would be great to have the ability of anchoring directly to the comment and/or line of code by having these with specific ID's on the DOM, like

https://reviewit.mycompany.com/projects/1/merge_requests/478#line-1257
or
https://reviewit.mycompany.com/projects/1/merge_requests/478#comment-1257

Delete users should not destroy the database entries, but just disable the users, so we keep the history, i.e. user comments, etc...

Add a confirmation dialog to the accept button to avoid accidental accepts

Sometimes you push a MR, it's reviewed days later and you need to update it, so after some days you (or at least I) may had forgotten what was the local branch name for that MR.

So the proposal is:

you are on branch foo, push a new MR, the MR with id: X is created, so reviewit can rename your local branch to mr-X-foo.

An option to disable such behavior should also be added, but I think would be nice to have this as default behavior.

Use blame to detect the modified lines and suggest potential reviewers.

Inspiration: https://github.com/facebook/mention-bot

This can be done entirely on client side using local storage.

Updated MRs would have a icon, or something else.

The user should have the ability to start/stop watching an MR.

1. The MR owner is added to the MR watch list.
2. Everyone that comments in the MR is added to the watch list.
3. Any user can remove himself from the watch list.
4. Any user can add himself into the watch list.
5. Only people on the watch list receive email about MR updates.

CI information should be cached in case of success and failure, besides being show on merge request list.

Integrate devise messages with flash message(#13) to standardize the messages in the whole application.

It should be calculated based on last time a comment, patch or the MR itself was changed.

Ooops, that's true, we are using git show instead of git format patch to send patches.

So just a group of users can edit the project settings.

When we have a big list of the finished reviews would be nice to have a way to looking for something specific like commit messages or descriptions.

If you create a merge request but no files match the pattern used by the linter the linter flag is set as failed, but it didn't.

If the project linter configuration changed, the CLI should detect, get the new configuration and re-run the linter.

Cancel a MR through the CLI doesn't ask for any confirmation

Problem: Is not clear which fields are required. (usability)

This will easy the review of MRs.

When a binary file is a image (jpg, tiff, png, etc.) we should show them in the diff page.

Don't let the user approve/abandon an MR is it was updated in the background

License this project so I'll be able to make some contributions to it

Should be possible to regenerate the authentication token (used by CLI) in the web interface.

Allow the reviewer/commiter change the target branch using the web interface.

Gitlab CI integration is broken for gitlab 8.x

Use markdown on comments, a client side JS should solve this.

review cleanup would do a git remote prune and remove any local branches relative to accepted or abandoned MRs.

To reproduce:

1. Enable CI integration
2. Create a tag in the project repository, e.g. foobar
3. Create a MR in the project, targeting the foobar tag.

Reviewit will create a tag named mr-xyz-version-w when the CI integration is supposed to create a branch based on this branch.

If no branch exists matching the MR target (nothing or only a tag), nothing should be pushed to CI.

In long commit messages that have line breaks on it's messages, I'd like to suggest getting only the first line of the commit to show up as a title and the following lines to be underneath.

Here's an example (screenshot): http://d.pr/i/1dbgs

Below a few example of most known applications that should be considered:

• Campfire,
• Flowdock,
• HipChat,
• Sqwiggle and,
• Slack.

i.e.: A new merge request has been sent. Click here to see it directly in your browser.

JIRA has a REST API, so would be nice to be able to post comments on JIRA when a new MR with some tags gets created and/or merged.

https://developer.atlassian.com/jiradev/jira-apis/jira-rest-apis/jira-rest-api-tutorials/jira-rest-api-example-add-comment

Add code climate badge to track our code quality. Further informations: http://docs.codeclimate.com/article/170-code-climate-badges