Development toward Wagn 2.0 has centered around "modules" -- easy ways for coders to extend Wagn's functionality without having to learn their way around all of Wagn's codebase.
Now we're putting out an API "proposal" to our community. If you're someone who might someday be interested in writing a Ruby module here or there, have a look and let us know what you think.
Blessed vs. Possible
The initial API release will be somewhat limited in scope, because many aspects of Wagn's architecture are still evolving rapidly. When we "bless" a piece of our API, it means that we're not going to change it without lots of fanfare and early warnings.That doesn't mean we'll prevent you from using unblessed API; it means we're not going to break our backs to support anything unblessed. So if you use unblessed code, we celebrate your bravery, but know that future releases may break your modules without much warning or apology.
+API+best practices
An area to record helpful habits for private modules as well as conventions to facilitate adoption and compatibility of public modules.
We need more examples of what this might be, for example use of * in rightnames. In general managing the Wagn namespace, etc. What else is in here that we have already identified?