Tipping the apple cart?

[Nate Graham]

Am 01.07.19 um 15:37 schrieb James Ramsay:
> Is it primarily the previous discussions so that you can better 
> respond directly via email? If so, this proposal to include entire 
> discussion thread in email notifications 
> (https://gitlab.com/gitlab-org/gitlab-ce/issues/40557) which Zsolt is 
> looking at might meet your needs. What do you think?
> 
> GitLab does support leaving review comments in bulk rather than one at 
> a time but it is currently in the GitLab Premium tier. There is a 
> proposal (https://gitlab.com/gitlab-org/gitlab-ce/issues/60690) to 
> move it to the Core tier (free, GitLab CE) being considered.
>
> Do you have any other feedback about GitLab? I would be very 
> interested to organize a video call to hear any wide ranging thoughts 
> on what it would take to make GitLab code review better than 
> Phabricator and Reviewboard for your needs if you can spare the time.
>
> Best,
> James

Thanks for being willing to engage, James! It's very much appreciated.

Backporting the Merge Request Reviews feature [1] will be a big 
improvement to address email overload and I look forward to that.

In my own trial use of KDE's GitLab instance, the other source of email 
overload is the fact that it sends one email per action, rather than 
offering a web-based notification center capable of batching up 
notifications that all pertain to the same Issue or Merge Request 
(proposed here: [2]).

The problem with the "one email per action" approach is that it 
implicitly assumes a workflow where everyone is sitting at their 
computers all day waiting for emails to come in, and triaging them 
accordingly [3].

This doesn't describe most members of the KDE community. The vast 
majority of KDE contributors are volunteers who can devote a few hours a 
week to the project, and are virtually never sitting in front of a 
computer all day handling KDE-related emails in real time as they come 
in. Even those who can are generally developers who find handling email 
a distraction during periods of time when they're trying to write code. 
We already have a problem with people filtering, auto-deleting, or 
ignoring emails. The more emails people get, the more acute this issue 
becomes.

Some implementation of what's proposed in [3] would be hugely helpful to 
remedy the issue originally described in this thread, and would be a big 
step up from Phabricator rather than a downgrade or side-grade.

Nate


[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/60690
[2] https://gitlab.com/gitlab-org/gitlab-ce/issues/64183
[3] https://gitlab.com/gitlab-org/gitlab-ce/issues/29488#note_25414909