Re: Gitlab Migration

[Tim Cross]

Daniel Fleischer <danflscr@gmail.com> writes:

> Tim Cross [2021-08-27 Fri 11:01]  *wrote*:
>
>> I'm not sure this is true. I think virtually all developers are forced
>> to suffer email, but a gorwing number don't use it. Often, all the
>> discussions, notifications, comments etc are actually consumed via a
>> mobile 'app'. For these users, logging into their inbox is frustrating
>> and inconvenient because their inbox is full of pointless and old
>> messages/notifications/alerts they have already seen/received via other
>> channels. For these users, the primary reason they have an email address
>> is to have something to put into the 'login' box for web services they
>> use. Telling these users to use email to submit a patch is very similar
>> to me being told when I started using email that I had to send in a hard
>> copy via snail mail.
>
> It's a very intersting point about what email represent to different
> people that arising from this discussion. I'm half your age and use
> email for 2 reasons:
>
> 1. It's an identify for today's web. As such, it's becoming the main
>    tool for tracking (especially as cookies phase out), so I use
>    multiple boxes and regard them is disposable and spam-infected.
>
> 2. Receiving official documents from institutions.
>
> I don't talk to family, friends or coworkers via mail. Personally, I
> think it's old, not secure or private by default, very inconsistent
> (HTML rendering is arbitrary vs. text, multiple MUA) and just can't
> imagine using it as a software engineering tool.
>

Yep, that mirrors what I'm seeing as well. Many younger users really use
it primarily to provide a unique identifier (login) and for when they
have to deal with institutions that don't provide other alternatives.

The other interesting trend I'm seeing is with many companies now
working to minimise email as part of their internal/external workflows.
Many companies are finding it a huge resource sink, cause of unnecessary
stress/pressure on staff, source of significant security concerns and a
real problem for records management.

>From the Emacs project perspective, providing alternative web based
workflows similar to what github/gitlab/sourceHut provide would be
beneficial. The challenge seems to be in finding software which meets
FSF requirements. In particular, a solution which is mature enough and
is not based on non-free Javascript libraries.