On 5/19/2020 1:48 PM, Russell Adams wrote:
> On Tue, May 19, 2020 at 01:50:26PM -0500, James R Miller wrote:
>> I think an actual issue tracker has merit to large projects.
>>
>> And I don't think simply saying "we've always done it through a ML" or "$FOO
>> project is bigger than us and uses a ML" is good enough. $FOO project may very
>> well increase efficiency, code quality, and/or participation by implementing
>> an issue tracker.
>>
>> A project to consider then, might be some sort of system that interfaces with
>> the ML (as well as a simple REST api so that issues could be submitted from
>> inside emacs directly), that creates some sort of org-based issue tracker, and
>> then ox-html exports to a static web page or pages.
> 
> My point about duplication of effort stands. Who/how/which solution? Who has to
> maintain it, and does that make two places to check while managing bugs/patches?
> 
> Please note I'm not a complete luddite, nor have I any real influence in any
> decision.
> 
> However I'll point out that with limited resources, the onus to sufficiently
> justify a major change falls on the person(s) making the recommendation. Change
> "just because" or "it's prettier" tend to fall on deaf ears in technical
> communities.
> 
> I'd argue that code quality is more improved by the proper application of
> version control than whether bug reports are web based. This appears to already
> be the case.
> 
> If email is unmanageable, I'd assert that perhaps the user has a poor quality
> mail reader that lacks threading support, and perhaps they should find a better
> one.
> 
> Is there a problem with submitting issues via the mailing list? Has something
> gone unaddressed? Do you have any statistics to show that there is decreased
> participation because you have to use email? Is something really inefficient at
> the moment? Did you have patches ignored?
> 

This idea that the tools used by a potential contributor are inadequate
misses the point. If the intention is to keep a project going, or better
yet increase the number of contributors, tools have to be used that will
be convenient and familiar to those thinking about contributing.

For better or worse, the workflows embodied by Github and Gitlab are
familiar to the current generation of potential contributors upon which
sustaining a project will depend.

Holding up the 'Linux uses email for development and thus any project
doing similar is right' fails to recognize the peculiar nature of the
Linux kernel (and its developers) and neglects the thousands of projects
that have increased their visibility and participation by using tools
such as Github. I agree that Github/Gitlab may not be the best choice
owing to their stance or implementation related to software freedom, but
an honest discussion of alternatives seems prudent.

-gyro