Sponsoring Djangocon EU 2019

Django has been at the core of Isshub from the beginning. In fact, Isshub is entirely based on open source software: language, framework, databases engines, and everything else that is used to host the product.

And without these open source tools, Isshub would simply not exist.

So, as a mean of contributing back, we thought than supporting a conference would be a good idea, and at the same time, would allow more people to get to know us and, why not, discover a new and relaxed way to manage their issues, code requests and notifications from Github and Gitlab.

So we're proud to announce that Isshub is officially a sponsor of the DjangoCon Europe 2019, which will take place in Copenhagen, Denmark, from 10 to 14 April 2019.

What is DjangoCon? As indicated on the conference website:

DjangoCon Europe is run by the community for the community: We are the 11th European conference, made up of Django practitioners from all levels.

This is not really our first sponsorship: we were a proud sponsor of the "Rencontres Django", aka DjangoCon France 2018 but it was a relatively small conference compared to its European counterpart which will see people from all other the world.

We are excited about this new experience and we look forward to sharing with you if you are in Copenhagen at this time.

Meet... Gitlab!

Less than a year ago, Microsoft bought Github.

Even if it doesn't change anything, a lot of people got scared and moved to Gitlab despite that at the time... Gitlab was hosted on Microsoft Azure (but it changed a few weeks later)

A few years ago, another change from Github already had the same consequences.

So it's now a thing: Github has a serious competitor, and at Isshub we decided to take that into account and integrated Gitlab, in addition to Github, into our product.

It was a hard work because everything was focused around the Github models and API, and there are a lot of differences between the two git hosting companies.

But the work is now done, and you can enjoy having a clean way to view your Gitlab issues, to review your merge requests, as you did for Github.

So you can have in Isshub a Github account and a Gitlab one (in fact many of them), switching to one or the other very easily.

We decided not to mix in the product the content of distinct accounts, but the switch is easy: you don't have to log out and log back in with the other account.

We added some niceties while rewriting some parts of the applications, like the way to mark issues as read or waiting (at any point in time of the issue), some small tweaks in the UI, etc, etc.

Some things are specific to Gitlab. The main points are:

  • with the free Gitlab plan, you cannot assign many users to an issue
  • we managed to have a clean way to never have to scroll to find a thread: every comments are at their place in the issue timeline, with an easy way to see the whole thread.
  • we managed to have clean "reviewed"/"discarded" comments for projects that don't have Gitlab reviews activated because of the feature not activated in their plan

We hope you'll find this useful to be able to use the same UI to manage the content of two very different git hosting products.

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

Sponsoring

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 www.isshub.io 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