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"
