Project structure

A project may be structured as follows:

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. a very short outline of useful functionality modules. The wiki is a better place than base repositories 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.
  • Somehow a connection must be created between Wiki and repositories. And such eco modules listings are one possiblity for achieving that.

• Tagging: The projects' documentation/guidance is tagged using Wiki categories in accordance with the categories listed in the module's feed XML (if using package manager 0install for release distribution). This is slightly redundant but necessary because the wiki lists not yet released projects and may serve as an overview to many people (mostly developers) 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).