add more examples for spec inclusion; add interoperability as a core value

proposals/1779-open-governance.md

@@ -129,6 +129,7 @@ subjective areas.  The values we follow are:
 
  * Supporting the whole long-term ecosystem rather than individual stakeholder gain
  * Openness rather than proprietariness
+ * Interoperability rather than fragmentation
  * Collaboration rather than competition
  * Accessibility rather than elitism
  * Transparency rather than stealth

specification/proposals_intro.rst

@@ -62,6 +62,7 @@ their proposed changes to the Matrix protocol:
 
 * Supporting the whole long-term ecosystem rather than individual stakeholder gain
 * Openness rather than proprietariness
+* Interoperability rather than fragmentation
 * Collaboration rather than competition
 * Accessibility rather than elitism
 * Transparency rather than stealth
@@ -110,7 +111,7 @@ applied:
    For instance, video conferencing is clearly a feature which would benefit
    the whole ecosystem, and so the spec should find a way to make it happen.
  * If the spec already makes the feature possible without changing any of the
-   spec *or implementations*, then it may not need to be added to the spec.
+   implementations and spec, then it may not need to be added to the spec.
    For instance, video conferencing done by widgets requires no compulsory
    changes to clients nor servers to work, and so could be omitted.
  * However, if the best user experience for a feature does require custom
@@ -127,6 +128,19 @@ applied:
    for doing so), or to keep it as a widget-based approach (optionally with widget
    extensions specific for more deeply integrating video conferencing use cases).
 
+As an alternative example: it's very unlikely that "how to visualise Magnetic
+Resonsance Imaging data over Matrix" would ever be added to the Matrix spec
+(other than perhaps a custom event type in a wider standardised Matrix event
+registry) given that the spec's existing primitives of file transfer and
+extensible events (MSC1767) give excellent tools for transferring and
+visualising arbitrary rich data.
+
+Conversely, features such as reactions, threaded messages, editable messages,
+spam/abuse/content filtering, are all features which would clearly benefit the
+whole Matrix ecosystem and require both client & server implementation
+changes across the board to be implemented in an interoperable way, and so
+necessitate a spec change.
+
 Process
 -------