Re: Support for launching the FSF forge

[bill-auger]

On Sat, 4 Apr 2020 14:50:42 +0200 Karl-Philipp wrote:
> My motivation is to finally/even faster be able to contribute
> to free software projects which are using mailing lists and
> lack appropriate tools for collaboration on software
> development.

FWIW, for the sake of a balanced discussion, someone should
address the implication that GNU is "behind the times" for using
antiquated project management tools - no one yet has, so i
suppose i am that someone - it is a common misunderstanding of
the situation, due to a certain familiarity bias - namely: that
people naturally tend to prefer the tools which they first
learned, and resist learning new ones (or even older
"tried-and-true" ones)

for many people today, that first project management and
collaboration tool was github - the things that those people see
as lacking in older forges such as savannah and sourceforge are
what was coined in the forge-fed discussions as as "git-isms"
and "github-isms" (pull requests, merging code with a
mouse-click, "stars", @mentions, and such) - they are all
things, that only people for which github was the first forge
they had ever used, have come to expect as essential; but
software development got along perfectly well before git and
github - because forge-fed aims to be maximally generic for all
development and management workflows, it was important to sort
out which features were generally essential and which were
workflow-specific, tool-specific, or optional conveniences - it
was concluded that these "git-isms" and "github-isms" were
features which should be supported, because many people expect
them, but were not to be specified as essential, because they
are not actually essential for the purpose of project management
and remote collaboration

many people consider mailing lists alone, to be completely
adequate for remote collaboration and software development -
forges such as savannah and sourceforge were as adequate for
project management before git existed, as they are today - their
primary benefit was not because they are websites, but mainly
because web and email hosting was much more costly and difficult
to maintain then, than it is now - the website component was, and
still is, primarily an entry point for users and new
contributors to discover the project, download the software,
or join the mailing list - one could easily argue the opposite
use-case (and they do), that it is the newer forges such as
github and gitlab, which are lacking in support for an essential
collaboration tool: patches via email

if mailing lists were inadequate for remote software
development, and/or the web was an essential component of
software development, then all such webby convenience tools for
project management could not exist, because they were built on
top of all of the software which was built before them, and
without them (gcc, linux, apache, etc)

there was no web when those foundational softwares were
developed; yet they developed quite nicely, in spite of that
_perceived_ impediment - as i understand, still today, linux is
developed primarily by patches sent over mailing lists; and many
GNU project maintainers are content keep the same workflow as
well - many may even resist adopting the newer web-centric
workflow, because the benefit is not as obvious as it seems, to
those who have come to expect it as the norm - i.e. the only
software development for which a web browser is truly an
essential component, is web development - that fact is simply
more obvious to people who are already accustomed to the
traditional email workflow

some years ago, i started suggesting that savannah be upgraded
to one of the more "modern web" interfaces; and discussed the
idea with several GNU project maintainers - a few of them had
already decided to host their own instance of gitlab; but the
majority of them did not see any need for it - this new webby
forge which is being considered now, is primarily for the
benefit of new people, who are not already involved in GNU
projects; and it is unclear how many GNU projects will actually
want to use it - that was my very point for suggesting it
though, as a way to invite new contributors - it was not because
those webby bells and whistles are essential; but simply because
many people today are accustomed to that workflow, and tend to
resist learning another - i would characterize the plan more as:
"lowering the barrier-to-entry" than: "keeping up with the times"
or "compensating for inadequacies"