What are the fundamental requirements for communication and decisionmaking decision-making related tools or systems at the ASF? Why is each requirement there?
A key tenet of any communication systems - and systems—and especially of any archiving systems used for them - is them—is that the ASF can be master of our own fate. The ASF needs to provide long-term access and search to any decision-making processes of our projects - even projects—even after a project may have gone to the Attic. Similarly, communication systems (in general) should strive to allow anyone to participate in our projects, no matter their location (timezones), legal issues (i.e., can't sign some service TOS), bandwidth issues (can only download slowly/, only at certain times), or other similar cases.
Core Requirements For Communication Tools
While it would be nice-to-have if the ASF could self-host all systems we rely on, in reality the requirements of tools where projects may actively collaborate are de facto less strict than our requirements for archives. For example, many projects use Slack productively, a donated service we do not directly control. However, in cases where we need a record of actions or decisions, we can always export data into our lists or other archives.
...
- Contributors send mails to a list to have a discussion and hold a vote, and most contributors are simply following along by reading their mail client.
- When referring to last year's release, contributors will typically go to lists.a.o to search for the release notes, and then send a link to the archived email(s) for a new discussion or reference point.
- For mailing lists, the 'archiving' is done automatically and instantly by infrainfrastructure's mail systems.
- For other communication systems, we need to decide on some process to periodically archive a set of discussions, and where /and how to archive them.
Core Requirements For Communication Archives
Archiving systems must support a number of conceptual features. These are features needed after the fact, and the ways users access the data may be different than from a live communication tool (i.e. reading a mail, vs. looking on lists.a.o). Note: an outside group at Harvard has come up with their own "SLOPI" archiving requirements which are strikingly similar, and were inspired by their work in ASF projects.
Self-Hostable
Self-hostable: the ASF must be able to self-host the entirety of an archiving tool if needed. This hosting must be practical for the infra team to accomplish (considering costs, skills, team effort, etc.).
Rationale: vendors - , like SourceForge - , might go out of business, raise prices, or change their business model to be unfriendly to the ASF or our users. We need to be able to backup both the data and any site access tools independently of specific vendors. Similarly, a perfect archiving system won't matter if the complexity is beyond our infra capacity.
User Accessible Via Browser
Archiving systems must be accessible by any user, even users who might not participate for reasons above (can't sign Slack TOS, low bandwidth, whatever). Web browsers are a sufficient lowest common denominator. Any publicly-archived communication channel should be available to any user with a standard browser who can route to our servers, without accepting any agreements besides the Apache license.
...
Rationale: ensuring archives are accessible to any user, now and in the future, is important to not exclude any potential contributors.
Structured And Searchable
Archives must be richly searchable, and provide at least a general level of searching like lists.a.o: full-text search; by date ranges; by author; etc.
Archives must also include the obvious categories (i.e. which project it belongs to; dev@ or user@ or private@ kind of discussion, etc.) or discussion threading (like a mailing list or Discourse does) as facets for searching.
Permanent URIs
URIs for access - either access—either of individual messages, or common by month, by thread, etc. methods, must be permanent URIs. This could include redirects if needed.
Rationale: the ASF encourages long-lived projects, and we often refer to decisions from years past. Similarly, even in the Attic, we ensure that all project materials - including archvies of communications - are materials—including archives of communications—are still available, at the same locations. This ensures that if we ever want to unbox an Attic project, it's simple.
Reliable
Reliable: all archives should be practical for infra infrastructure to back up backup periodically to proper offline storage. This ensures security of data for the life of the ASF, at least 50 years.
More? More rationales? Are there any other details of core requirements that are constant? In practice, the details of how we'd implement something depend on how important the data is to the ASF, and our infra and financial capacity. For example, while we might love to have Slack/WeChat conversations archived and threaded instantly, perhaps doing it weekly would be sufficient for some projects (as a concept).