Re: Subversion's community health

Here is my suggestion.

Primary goals:

* Stability
   - because that's the stage in the project's life cycle
   - if anyone wants to invest in development, that's fine too, but is
not what the current stewards of the project should be concentrating on

* Availability
   - because stability for users (including admins) requires that they
can deploy it where they need it, and keep it up to date easily
   - availability is currently poor -- see "Software Distribution" in
https://blog.foad.me.uk/2018/12/07/svn-whats-in-my-head/

For Stability:

* encourage commercial engagement for project maintenance

* encourage community maintenance by accepting minor feature
contributions and experimental initiatives
   - don't let them compromise stability

* seek to remove or hide rough edges in existing features
   - e.g. hide experimental features behind an opt-in config

For Availability:

* support availability of up-to-date install packages
   - including today's cloud/container deployment platforms

* improve ease for downstream consumers using our releases
   - see Mark's response about Subclipse

How?

* invite companies to contribute their existing build systems
   - CollabNet, Assembla, RhodeCode, WANdisco

* find out what are the main desired target platforms
   - provide a reference build system for each platform
   - find and support maintainers for each platform

* change our release schedule to focus on maintenance releases
   - reduce friction in version numbering, compatibility, multiple
release lines

* improve ease of producing new releases, especially bug fix releases
   - automate the release steps (aim towards "one click")
   - reduce friction in backports and releases policies (voting, etc.)

-- 
- Julian