Re: Gitlab Migration

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 26.08.2021 22:41, Eli Zaretskii wrote:
>>> On 26.08.2021 20:59, Lars Ingebrigtsen wrote:
>>>> Many
>>>> don't use mail at all for development, and all they're used to is the
>>>> GitLab/Hub way of doing it.
>>>
>>> Email is used by virtually everyone (for example, to receive
>>> notifications about others' actions or messages), what's "unusual" for
>>> many is sending patches over email. Or inlining them in comments/messages.
>> No, Lars is right: I've heard quite a lot of people saying that they
>> feel uneasy to write email messages.
>
> While there are as many habits as there are people, perhaps we should 
> interpret
> it more like "write a first email message", to a particular mailing list.
>
> There is a whole list of worries a polite and careful person can associate 
> with
> that.
>
>>>> So it's easier for them -- it feels safe and familiar for them to do
>>>> development by clicking around in a web browser.
>>>
>>> We also have a bunch of formal rules for submissions which tend to seem
>>> intimidating. A CI with an automated checker running against all PRs can
>>> alleviate that problem.
>> Automation can alleviate only some of the violations, a minority IME.
>> For example, there's no automation known to me that can fix the commit
>> log entry format.
>> But anyway, what prevents us from having those same checkers running
>> on our machines as part of "git am"?
>
> The point is, someone who has never contributed before can more easily see all
> bugs/PRs/discussions from the outside, and when they file a PR, see the checks
> succeed or fail (with specific complaints and recommendations) without having 
> to
> involve a live person.
Hmm, some projects have thousands of issues, some remove solved issues. I am not
sure it is so easily discoverable. Also I see a lot of comments on gh advising
users to first search for the issue before posting, which makes me thing that
people are not so good to "look first" if issue is already solved.

> The ability to avoid bothering anyone directly (and risk a negative reception)
> can help avoid some of the worries.

Maybe Emacs project should be better at informing users about Emacs bug tracker:

https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs

and this one:

https://debbugs.gnu.org/

and debbugs package for browsing bugs directly from Emacs?