Analysis of interaction between development platform/practices and inclusion

[jennybc]

In Python, the move to GitHub coincided with and was very much wrapped up in the (successful) effort to increase the size and diversity of their core team.

Here’s an interesting blog post with some detail about Python moving from Subversion to Git/GitHub:
https://snarky.ca/the-history-behind-the-decision-to-move-python-to-github/

It’s good for understanding the link between the tooling and renewal and getting more “shoulders to the wheel”, be they from core contributors or not, URMs or not:

For an open source project, this is a bad situation to be in because if external contributors stop participating then the project slowly dies with the core developers as they stop participating and they are not replaced because there is no one to replace them with.
…
I said that what I wanted was 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. My pithy summary of what I wanted was the ability to review an external contribution -- from submission to commit -- all on a tablet while at a beach with WiFi (which I actually have in Vancouver so this wasn’t entirely a silly request)

It will be good to evaluate the current technical and human platforms for contributing to R and explore the potential positives and negatives of switching to something like GitHub/GitLab that is expressly designed to promote collaborative s/w development, continuous integration, code review, issue tracking, rich hyperlinking, etc.

A short exploration of this could be done by this group. But for a more serious exploration to be successful and not a waste of time, there would need to be buy-in and participation by R Core.

[jennybc]

Another interesting analysis of issues of tooling, process, and different interpretations of what open source means:

https://steveklabnik.com/writing/what-comes-after-open-source

[ColinFay]

Adding these two articles to this issue about plain-text email & Linux Kernel development, that relates to the topic of tooling & inclusion:

"Relying on plain-text email is a 'barrier to entry' for kernel development, says Linux Foundation board member": https://www.theregister.com/2020/08/25/linux_kernel_email/

"The ability to send a plain text email is not a skill people care about (mostly)": https://ypsidanger.com/17819/the-ability-to-send-a-plain-text-email-is-not-a-skill-people-care-about-mostly

[elinw]

What might be great would be a package that implements creating an SVN patch from a git repository (see https://stackoverflow.com/questions/708202/git-format-patch-to-be-svn-compatible) and also applying an SVN patch locally for testing. One of the issues in bugzilla is that there are a lot of patches there that seem never to have been tested.

[jennybc]

Relevant documents to partially emulate in terms of how others have evaluated such options:

PEP 512 -- Migrating from hg.python.org to GitHub (so: what actually happened)
https://www.python.org/dev/peps/pep-0512/

which followed an evaluation of two different proposals:

PEP 481 -- Migrate CPython to Git, Github, and Phabricator
https://www.python.org/dev/peps/pep-0481/

PEP 507 -- Migrate CPython to Git and GitLab
https://www.python.org/dev/peps/pep-0507/

[jennybc]

Key piece of feedback:

What sort of incremental steps are available? What sort of bridge / dual solution is feasible?

[jennybc]

https://searchsoftwarequality.techtarget.com/news/252488908/Oracle-moves-OpenJDK-to-Git-and-GitHub

JEP 357: Migrate from Mercurial to Git
https://openjdk.java.net/jeps/357

JEP 369: Migrate to GitHub
https://openjdk.java.net/jeps/369
this document is especially good for enumerating reasons for the switch to externally-hosted version control, balancing workflow of existing contributors vs. the hoped-for new contributors, listing and mitigating specific concerns re: risk of change

[jennybc]

Migrating to Git from SVN, from Axosoft (makers of GitKraken)
https://blog.axosoft.com/migrating-git-svn

[llrs]

A closer experience might be the move of Bioconductor (whose leader was one of the R Core member) from svn to git and using github as review tool for new software added (and actually hosting everything from the website to the software used on the build machines). I don't think there is any analysis of before/after but perhaps it could be generated.

[lawremi]

From a purely technical perspective, there is a lot to learn from the Bioc experience, and maybe we could even have the same people do the work. From the political perspective, the opening of the Python community is an interesting one. I wonder if that was simply a matter of building inertia, or if there were people actively opposing it (like in R's case).

[jennybc]

I am optimistic that we could learn more about this history, from Python, if we wanted to and if it might prove fruitful in charting a course for R. We certainly have a few personal contacts that have first-hand knowledge.

And, for sure, yes it's even easier to connect with the team who worked on this for Bioconductor.

[llrs]

Recently I found some references that could be interesting for your consideration:

An analysis of StackOverflow influence on the R-help mailing list
Impact of switching bug trackers: a case study on a medium-sized open source project: Some plots from moving from bugzilla to github:

A program to move issues from bugzilla to github: https://github.com/berestovskyy/bugzilla2github

[PythonCoderUnicorn]

Hello Everyone,

I don't have an article or plot to post, but do have experience with being part of a Python conference, and the Python community in general. From my beginner-to-Open-Software projects lens, R is 10x more inclusive and supportive overall than in Python.

In Python, suffice to say there is no Hadley Wickham type people in the community. I follow the few LGBTQ people I met on in online conference, but Python LGBTQ / inclusivity community is nowhere near the level that R has.

I comment to share that in my view, Python should take a page from the R community, not the other way. I like Python but in R i feel welcomed that I didn't really get from Python community.

[hturner]

In terms of incremental steps, we can try to address these related issues:

• Including git/SVN cheatsheets in the guide r-devel/r-svn Mirror: Contribution Docs: GIT Cheatsheet + GIT IDE rdevguide#64
• Using r-svn for patch testing and review Describe GitHub workflow: create a patch from pull request to r-devel/r-svn rdevguide#23. Need to be clear in the guide and in the r-svn repo description that it is okay for testing but not for bug reporting/discussing with R Core.