Julian's thoughts on what we could and should do with the Subversion project as a whole.
- keep using Open technologies
- keep plain email the baseline standard of communication
- integrate 'forum' and 'mailing list' forms of access
- integrate long-form and chat-form if possible
- integrate archives / logs, permalinks, searching
Email: Forums and Mailing Lists
Problem: Simple old mailing lists are inconvenient for new and occasional users. They have weak or no integration with their own archives, our issue tracker, etc.
Some proprietary forums e.g. Google groups already attempt to mirror and integrate with our lists, with some degree of success, but we are mainly ignoring it.
We should seek to integrate better with forums. For a start: let users know that it's an option for them (on our 'mailing-lists' web page); and see if we can make some better steps of integration (such as unified permalinks).
For a longer term solution, I wonder if any suitable open source software exists, or if an ASF group might consider developing/adapting something.
- Pony Mail can substitute as a simple forum interface. See, for example, https://email@example.com If you log in, you can post messages directly from the web UI.
Chat (IRC, Matrix)
Problem: The IRC chat systems we use are inconvenient for new and occasional users. They have weak integration with archives, issue tracker, etc.
Use Matrix as an upgrade path from IRC. That is my strong recommendation.
Matrix is ready for immediate ad-hoc use by individual participants in our IRC channels, through the Freenode bridge operated by matrix.org, and is being used in this way by at least two svn-dev members.
In future the ASF should run its own Matrix infrastructure: server, bridges, etc. The ASF would then control its own data, its own user accounts, and its own integrations with archives, commits, issue trackers, etc. Usability advantages: use ASF single-sign-on; install specialist bridges/integrations.
- encourage users to consider using Matrix to access #svn-dev and #svn
- share with the rest of the ASF – on firstname.lastname@example.org or email@example.com?
Integrate archives / logs, permalinks, searching
Problem: Past communications are scattered across systems and storage locations, with no consistent archives or permalinks, so cross-referencing is difficult and non-permanent. Our issue tracker and wiki provide only links that are tied to their current provider technology.
The types of information include:
- Short-form chat (IRC) archives: Matrix-Static, irclogger, ASF Wilderness IRC logs.
- Email/forum archives: haxx.se, ASF Pony Mail, the old Tigris lists. (The old Tigris mailing-lists system used to provide a permalink to the archived version at the bottom of each mail delivered.)
- Issue Tracker: the current Jira issues, the old issuezilla.
- Wiki pages: the current Confluence, the old MoinMoin.
An important step is to develop a URL "permalink" scheme to refer to our various resources. These would be technology-ignorant URLs, all under
subversion.apache.org, like "
A baby step is the '.message-ids.tsv' file in our web site directory, holding a mapping from haxx archive URLs used in our web pages to email message ids, with (in the commit log message) a script to generate it. There is, as yet, no automation to use the mapping in any way.
- start documenting a URL-space map for our resources
- populate one entry, e.g. "/issue/<number> → issue <number>"
- implement some simple automated handling (e.g. redirects) for that
- well, well... we already have this in our .htaccess which covers that exact case along with some aliases:
- start using it: update existing direct links to point here instead; publicize it
Deeper integration: A permalink URL should not merely redirect the user to its technology-specific target URL, but present the target in such a way that other inbound and outbound URLs also use the permalink form. With a big third-party system like Jira or Confluence the feasibility of that is going to depend entirely on whether the system has built-in support for that usage.
Problem: Subversion packages are outdated or unavailable for many platforms, especially server/cloud environments (e.g. Docker) and mobile (e.g. Android).