Probably, especially if it matures. At the moment though, I don’t think so. Some of my thinking… sorry if it’s a bit disjointed.
The community needs a central location to iterate on how to document interfaces. No single code repository is that central location. So, in a sense, this is a mechanism for creating a “standard template” that works.
Having documentation here is a good way to route people to the correct code repository. I like the layer index. But how do people find the layer index in the first place? Why is it in the github.com/juju namespace, but the layers/interfaces are within the github.com/juju-solutions namespace?
Interfaces are not specific to a specific code base. They represent a contract between multiple code bases. Every provider and requirer is a stakeholder in the interface. Reactive layers have treated interfaces that way. I believe that’s why there is huge fragmentation. The current approach creates knowledge silos by design.
We will need to create a neutral space for transitioning towards the new charming framework. Coupling documentation to a code repository will make that transition even more difficult.
As a wider issue, I believe that we, as a Juju community, need to accept that developers want to build their own systems for writing charms. @maaudet and @zicklag are proof of that. Coupling an interface with a code repository limits the ability of people using multiple systems. They should be able to interact with charms that they trust, without importing code into their own projects that they might not trust.
Thinking again of the knowledge silos problem. Right now, every charm developer has their own way of documenting things, right down to the build system and layout. Most charms use a partially complete README, others use Sphinx, others have a custom Markdown-based system, …