Multiple actions on Github notifications

Last year we added the multi-select feature on list of issues, which allows to make the same change to many issues in a list.

But this feature was missing from the list of Github notifications. It's a list of issues, but not the same kind, because not related to a single repository.

So we added the multi-select feature, but it only allows you to mark as read/unread and active/inactive many issues at once, which can really be useful if you have many notifications.

For example, to mark all the notifications from a specific repository, before that you had to do it issue by issue.

Now it's a lot more faster: filter the list on a repository, then activate the multi-select feature, select all the issues, and mark them all as read!

Create issues from anywhere

Until now, to create an issue on a repository, you had to go to a page related to this repository, for example its dashboard, using the repository switcher on the top left.

Now, when you press "c", the modal window that open to create an issue, has its own repository switcher at the top so you can now easily create an issue from any repository you have the right to do so.

Of course, by default, the selected repository is the one you are actually on!

Code review improvements

Instead of focusing only on replicating features that could be found on GitHub itself (even if it's necessary to avoid going back and forth between both platforms), from time to times we try to add small things than, when added up, can make the whole experience a lot better.

This time it's about code review, a big part of the IssHub platform.

We already saw here how a pull request evolves in time and how we could mark some parts of the code as reviewed.

Mark code as reviewed

But what is "reviewed" anyway? Did I see this chunk of code? Did I validate it? Rejected it?

There were no way to know... until now.

Now, for each chunk of code (and remember than you can still split a chunk into many), you have many choices:

  • not reviewed (by default, or you decided to mark it that way)
  • ignored (the chunk will be collapsed)
  • not sure (you did a pass on it but are not sure yet if you accept it or not)
  • refused
  • accepted

You can of course do this for a whole file instead of doing it chunk by chunk. What's also new is that by doing this chunk by chunk, the review status of the file is updated, and you even have a review progress bar for the whole pull request:

17 - Files tab - review visibility.png

In addition, you can filter the files to display depending on their review status, and even update the review of many files at once, using the top right menu:

13 - Files tab - menu.png

And you can easily filter the issues list to display only the ones you started to review:

18 - Filter on reviews.png

Mark comments thread as read/waiting

Often, a review consists of multiple passes from the reviewers and the author, with comments, grouped in threads related to some lines of code.

We added a simple way for you to keep track of the threads you read and the threads you expect an answer.

This way, the next time you'll go on the pull request, you can ignore some threads and focus only on the work to be done:

19 - Review tabs.png

And you can easily filter on issues where you have something new to read:

21 - Filter on marks.png

Other improvements

Of course among these two big new features, we tweaked a lot of things. For example:

  • Pass the mouse over the number of files touched in a pull request/commit and you'll the kind of files that are touched. Useful to know if you only want/have to review JS and the code is only related to CSS:

03 - Over file counts - detailed list.png

  • By pressing "s" while on an issue, you'll have the issue taking the full with of the screen. Useful if the code to review has long lines. You can now reduce the sidebar containing the list of touched files, to have even more horizontal space

  • You can now group pull requests (in the list or in the board) by status check or review status

  • In no-details mode in issues lists, the pull-request icon is displayed to easily make the distinction between issues and pull requests

  • You can open many commits at once in tabs, instead of clicking on each one

  • You can hide a comments thread if it bothers you to full read the code around this thread (it's the case by default if a thread is marked as read by you, without any new comments)

  • You can go to the start or the end of a thread

~ The end ~

See pull requests code evolve in time, and other things

Over the past few weeks, we focused on pull requests. We already had enough tools to make the life of reviewers easier, but we knew we could do better.

First, now that Github moved their GraphQL API out of beta, we could activate the Github review system by default for every repository.

And we also integrated the "request review" feature from Github, with some small additions:

  • filtering, with a default filter to easily see for a repository which pull requests you are requested to review
  • a board view, so it's easy for a manager to see who is expected to work on which part, and it's easy to change the requested reviewers of many issues at once

But the main features we added are: pull-requests states, and diff modes.

You know what's worth a thousand words? An image... So we'll use screenshots, by explaining them, to discover these two features.

Let's say you are in a repository and you see this in the activity feed:

It says that the content of this pull-request, ie the code, has changed.

You have some interest in the issue solved by this PR so you open it and go to the "Files changed" tab.

You now see this:

It seems like nothing changed except this little box on top of the files list.

Let's zoom in:

Yes, you read and understand correctly. You can see previous states of the pull requests, and compare between states.

A "state" is a version of the code of a pull request. It's not rare to update a pull request after our first push, for example to add more work, or simply after a review.

These states are helpful to see how the code evolved in time.

Let's see the very first state:

It will open a new tab in the pull request, showing the same "Files changed" view, but back in time:

The block presenting the state reflects where (when...) we are:

Now that we seen how the first version of this pull request was, let's be curious and see how it evolved.

The first step is to compare this first state, with the second one:

Again, a new tab will open, but this time, only the changes between the two states are shown:

We can see that there is only one file that was changed after the first push. It seems to be only spaces, though:

If I'm not interested in reviewing space changes, there is a solution.

Let's open the menu:

And click on "Attenuate white space changes".

The result is this:

We can still see the "-" and "+" showing what changed, but as there are only white-space, lines are not colored.

But it's now hard to read. It could be ok in some cases, for example a single line added, etc, but not here. We could use a "two-panes" diff....

Oh wait, remember the menu with the "Attenuate white space changes" and the hidden entry?

Let's unveil it:

Yes, a new mode. Let's click this "Display two-columms diff" menu entry.

The result is this:

We can now, on each side (left is "previous version", right is "new version"), read the code.

Ok so I read this, and now I want to see the next change.

To help you doing this faster, we included arrows in thte block presenting the state. Block that, in this "compare" mode, display the two states being compared:

Here there is no additional information about each states, which means that they are all based on the same branch (the branch for which the author wants the pull request to be applied on), on the same version of this branch. But:

  • If the branch changes between two states, the two branches (before/after) will be shown.

  • If the branch is the same but not its version (the HEAD commit), it's because a rebase was done, and it will be indicated.

On the left of the two states, we can see an arrow. We are comparing states 1 and 2, and this arrow allows you to see the next step: the comparison of the states 2 and 3.

Of course then you'll have the sam arrow, and a left arrow to see the comparison between states 1 and 2.

~The end~

It's the end of the presentation of these new features that, we hope, will ease your work with pull requests.

Invite your coworkers

If you are the administrator of an organization and you, or some collaborators, are using IssHub, you may find useful to invite other collaborators to use IssHub with you.

For this, to to "Your account", select the organization in the list on the top, and click on "Invite collaborators".

Now, simply fill the form, send it, and wait for your team to join!

If you're not the administrator, you can do the same by using the "invite some friends" button.

Win free subscriptions slots

Do you feel you could use IssHub more but are not willing to pay - or pay more - for now?

We have the solution for you: our referal program.

It cannot be simplest to use: go into your account, get the link, share it, and for each person subscribing to IssHub by following this link, you'll earn a lifetime-free subscription.

For this, simply go to new "invite" page on your account and you will:

  • find two referal links (one for the website, one for the application) that you can share the way you want
  • a twitter button to easily send a tweet to share this link
  • an email for to invite friends, with the referal links included, of course


When preparing our website to be out of private alpha mode (we're now live!), we added an interesting thing: sponsoring.

Any person, or organization, can sponsor a repository, for a small fee (see our plans).

By doing this, any person using IssHub can now subscribe to this repository for free.

For example, an organization could sponsorize one of its open-source repository, so any collaborator (member of the organization or not) could use IssHub to manage its issues and pull-requests.

And to let people now who their benefactor is, in the application, the sponsor is displayed near the name of the repository.

In addition, on the subscriptions page, there is a new tab dedicated to sponsorized repositories.

A handful of small enhancements

It's been a while without updates. But, believe us or not, we were at work more than ever.

First, we managed the whole website, including account management, plans, subscriptions.

Then, we made a lot of speed up of our backend: operations are now a lot faster.

And finally, we still worked on the app. Mainly:

  • The notifications menu was enhanced and it's now possible to manage an issue notification from the issue itself
  • Admins of organizations can now manage subscriptions for their members
  • Github projects changes are now displayed in activity feeds (project/column/card creation/edition/deletion)
  • Pull requests are greatly enhanced, but this will be for a next update

Reviewing becomes even more easier, again

A few months ago, we made reviewing easier, then even more easier.

Oops, we did it again!

The first step was to be able to mark, in a pull-request, a whole file as reviewed. So you could ignore it in the next steps of the review process, at least if it was not modified in between.

Then we added the possibility to do it for "hunks", ie parts of a file that where modified.

But, as reviewers ourselves, it was not enough for us, so maybe for our users.

For example a new file could be added, so with only one hunk, that could be long, and with only a small part that you wanted to comment, be you had to let the whole file as "not reviewed"

Same for a file with many hunks but a big one.

Now, in one click, you can split a hunk in two.

For example, for a new file, split a few lines before the part you do not agree with, and a few lines after, then you can mark the first and third hunks as reviewed!

And deleting a split is as easy: a single click.

Here are some screenshots:

Over the line you want to split on:

Click the split button:

A new hunk separator appears, marked as "manual split"

You can do the same a few lines below:

Then mark the first and third hunks as reviewed, and comment on the second one:

Protecting your writing

On Isshub you can create issues and, mainly, write comments.

And as for any text, typing and having your prose lost by a manipulation can be really frustrating.

It was easy to encounter this problem on Isshub until recently: start typing a comment and, for any reason, load another issue: the currently loaded issue is replaced with the new one, vanishing your text before you can do anything.

This is not a problem anymore!

Textareas are now "protected": as soon as you do something that may lead of to such a loss, a modal will tell you about it with:

  • a readonly textarea with your text ready to copy in your clipboard (already selected and focused, you just have to copy it)
  • a text: "You currently have text in a textarea. By continuing you may lost it."
  • a question: "Do you want to continue anyway?"
  • a button saying "No", that will abort your action and take you back to your filled textarea
  • a red button saying "Yes, continue", that will do your action, that may lead up to the lost of your text. But now you have the choice.

No published changelogs yet.

Surely isshub will start publishing changelogs very soon.

Check out our other public changelogs: Buffer, Mention, Respond by Buffer, JSFiddle, Olark, Droplr, Piwik Pro, Prott, Ustream, ViralSweep, StartupThreads, Userlike, Unixstickers, Survicate, Envoy, Gmelius, CodeTree