Project structure

A project may be structured as followed:

Repository

• Version control of development files.
• Distributed development.
• Automatic backups (due to existing on several systems of distributed developers / users.
• Integration with a versatile release and dependency tool.

Wiki

• As functionality modules collection/guide.
• Documentation
• Guidance, e.g. as a very short outline of useful functionality modules:

Because each module has its own repository and thus if it was then such a collection had to be located in the base repository. The wiki is a better place because such a collection is

• • subjective,
  • context dependent, e.g. eco focus versus gigantism focus, and
  • prone to incompleteness (new module created without knowing of it)
  • hard coded
  • or a movement may want to link to a certain eco-flavored fork of a base module giving the reader guidance in what repository / release to install.
  • Tagging: Somehow a connection must be created between Wiki and repositories. And such eco modules listings are one possiblity for achieving that.

Then the projects can be tagged properly using the Wiki categories. Tagging the documentation/guidance in accordance with the modules which is done using a cross platform package manager e.g. 0install. This is slightly redundant but necessary because the wiki lists not yet released projects and may serve as an overview to many people while searching for released projects should be done using the cross platform package manager.

Forum

Each wiki links to this forum topic for

• news / announcements all in one location without having to create a new website for each and every project / module.
• general discussion (while topic specific discussion for reference in commit messages goes into Github issues).