[Docutils-develop] SourceForge no longer viable to promote contributions

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

This post originates from: https://github.com/sphinx-doc/sphinx/issues/8039#issuecomment-668485530, in which I suggested that docutils hosting on Sourceforge is severly hindering its progress and, in turn, affecting aspects of sphinx.
Below I recap previous conversation about moving from SourceForge, provide some contextual analysis, and finally ask some questions of the maintainers.

Engelbert gruber suggested I look into the docutils mailing list.
As well as the open issue (https://sourceforge.net/p/docutils/feature-requests/58/), here is a summary of past conversation (and extracts):

- 2014: https://sourceforge.net/p/docutils/mailman/docutils-develop/thread/1400868919.8587.120887549.360547E2%40webmail.messagingengine.com/#msg32374278
Post:
> To be a little more blunt: this project looks pretty stagnant, and
> making it more welcoming to contributors could give it new life. People
> didn't migrate to git en masse just because because it was new and
> shiny; it legitimately has positive effects on open source projects.
Answer:
> I don't like to go to a host just because "everyone ist doing it". Maybe the hurdle for people that
> thrive there would be lower, but at the cost of current developers and contributors.
> I don't think that the Docutils core will gain much if it attracts a lot of contributors - the task of keeping the core consistent will become harder.
- 2014: https://sourceforge.net/p/docutils/mailman/docutils-develop/thread/CAEZF91tU2fqeE9YX34pt%2Bc-GZ5y9aNGZ37ytcZ0hiaVL%3Dh04zw%40mail.gmail.com/#msg31874379  
Post:
> I have a few issues with source forge... I don't find the interface friendly.  It's inconsistent. I am not up to
date with it, because everyone else is using something else.
> Even SQLAlchemy moved from bitbucket to github. Here is their rationale: http://www.sqlalchemy.org/blog/2013/05/25/sqlalchemy-migrated-to-git/
Answer:
> subversion does the job, so why change it .
- 2014: https://sourceforge.net/p/docutils/mailman/docutils-develop/thread/CAPE5o16_mH0ptH3HaaW5hQ4kU8y9jzNTF8gwkZLdPyzVgKe6Qw%40mail.gmail.com/#msg32877380 
Post:
> All I can say is that there is room for improvement in the documentation and possibly the code, a need for more work, and I feel encouraging open source participation is about removing every single possible barrier there is to people joining in a helping out
Answer:
no reply
- 2018: https://sourceforge.net/p/docutils/mailman/docutils-develop/thread/3c599bf9-626c-be4a-54c4-23fd6d5c9519%40gtec.at/#msg36220506
Post:
> Is there still a plan to move docutils development to github?
> I think it would ease contributions also for docutils, like for example for "nested inline markup".
Answer:
no reply
- 2019: https://sourceforge.net/p/docutils/mailman/docutils-users/thread/CAL1y04q6p7ecChcCfGu2GT0PUjUB6%3DrvL3UAFWm8UUXu9omjeA%40mail.gmail.com/#msg36807539
Post:
> I noticed there are more and more requests in moving the project over to GitHub, may I know why are you not considering moving over?
Answer:
> The reasoning is unchanged: don't change a running system unless there is a compelling reason to do so.
- 2020: https://sourceforge.net/p/docutils/mailman/docutils-develop/thread/CABiJP%3DJT9Fw0ngT8WLNENx0SbNDFM%3DxxsCKPJ1q4UV8FX%3DJURw%40mail.gmail.com/#msg36909691 in 
> Please justify your request (make an effort to persuade with evidence). Otherwise the request will be ignored.

You ask for a "compelling reason", here are some contextual statistics:

1. Of 222 packages provided in the https://docs.anaconda.com/anaconda/packages/pkg-docs/ distribution (a good selection of well used packages),
only docutils and appscript (which is now defunct) have home pages on sourceforge (see [1] for analysis code):
118 are on github, 2 on bitbucket and 1 on gitlab (most of the rest point to websites like RTD but the source code is still on github) 

2. In 2020, sphinx (who have 4 maintainers, the same as docutils) has merged 576 Pull-Request in to their source code, from 84 unique authors: https://github.com/sphinx-doc/sphinx/pulls?q=is%3Apr+is%3Amerged+sort%3Aupdated-desc+closed%3A%3E%3D2020-01-01.
In that same time only one patch has been merged into docutils from an external contributor by (well actually one of the sphinx maintainers) https://sourceforge.net/p/docutils/patches/search/?q=status%3Aclosed-wont-fix+or+status%3Aclosed-rejected+or+status%3Aclosed-out-of-date+or+status%3Aclosed-accepted+or+status%3Aclosed+or+status%3Aclosed-fixed

This suggests to me that (a) there is a large community of contributors motivated and able to contribute to python code, specifically in the area of documentation,
but (b) none of them are willing to learn a whole new CLI tool (svn or git-svn), workflow (patches over PRs) and UI (sourceforge, since it will not be relevant to any other python package development.

One could argue that docutils is "stable" and does not need any more development. I would beg to differ.
(a) in 20 years docutils has still not reached version 1. In fact there has only been 2 releases in three years, both of which are relatively minor: https://docutils.sourceforge.io/RELEASE-NOTES.html
(b) there is a full list of TODOs, of which only one item has been removed in three years: https://sourceforge.net/p/docutils/code/8531/log/?path=/trunk/docutils/docs/dev/todo.txt
(nested inline markup being a good example of something severely lacking from rST)

There are many many sources online discussing why Github/Gitlab is superior to SourForge (again this should not be a controversial statement, given that every python package has left it), but here are some extracts:

https://snarky.ca/the-history-behind-the-decision-to-move-python-to-github/
>  [Offers] a development process that was as simple as possible for core developers to use to review external contributions. This meant things like automated testing for patches, code coverage, patch merging through the browser, etc.
https://news.ycombinator.com/item?id=2739995
> Open source software is about programmers collaborating. GitHub makes that incredibly easy and straightforward. Want to join a project? Fork the code and tweak til your hearts content. Your code shows up in the network and other people can find/clone/fork/hack til their hearts are content. Want to contribute to a SF project? Um... contact the dev and hope the project isn't dead?
https://www.quora.com/Why-did-Sourceforge-not-achieve-in-the-2000s-what-GitHub-is-today
> GitHub provides a much more streamlined experience for both users and developers of all skill levels. SourceForge, while a flexible and useful site, just isn't going to get the same kind of adoption based on the the friction and skill level requirements to participate, off-putting ad based model, and lack of simple engagement features.

SO... my questions to the maintainers

1. From the past posts, no judgement, but I get the impression that the main barrier for transition is actually that you don't want any one else to contribute to docutils, and that you would prefer development was only undertaken by yourselves. Is this the case? If so do you feel that you personally have the time time to avilable to adress these TODOs and bring docutils up to version 1 within a resoinable time period? Or do you expect them never to be completed?
2. If you would like contributions, do you concede that as long as you are on SourceForge, such contributions will be few and far between?

Kind Regards,
Chris

----
[1]:
import json, subprocess
packages = json.loads(subprocess.check_output(["pip", "list", "--format", "json"]).decode()) 
homes = {}
for p in packages: 
    print(p["name"])
    data = dict([l.split(":", 1) for l in subprocess.check_output(["pip", "show", p["name"]]).decode().splitlines() if ":" in l])
    homes[p["name"]] = data.get("Home-page", None)