MoinMoinChat talks about a developer channel
/DeveloperTools - which tools you could use for development
/CodingStandards - guidelines on the development process, and code layout
/CommonTasks - how to correctly do recurring tasks, like adding a config variable
/CodeStructure - a tour of the most important modules, and how to find the best place to add new code to
ApiChanges - If you want to develop extensions or port them to a new MoinMoin version, you will find some hints about changes in the API here.
/UnitTests - How to use MoinMoin testing framework
MoinMoinAcknowledgements - who has contributed
MoinMoinExtensions (plugins) - Contributed code
/PluginConcept - macros, actions, parsers, processors, and formatters
/CreatingMacros - hints for writing your own macro
MoinMoin Concepts & Subsystems
The following pages contain the requirements, design, and docs for various MoinMoin key concepts:
/WidgetConcept - how to separate data aquisition from data display and navigation
/DatasetBrowser - displaying and browsing tabulated data
/Storage - explains the different kinds of system files and the directory layout
/WikiDom - new model for parsing, processing and formatting wiki pages
If your code has user interface texts, they need to use i18n functions to easily get translated. Generally what you have to do is this:
Try to reuse other localized text already in the code if it makes sense. The user will be happy if he gets the same familiar response instead of a new little different one, and the translators will be happy too.
MoinMoin2.0 - next goal
/HowToRelease - steps in the release process
- Tla / arch on arch.thinkmo.de isn't used any more.
- CVS on SF is very outdated and contains very old stuff.
moin/1.2, 1.3, 1.4, (0.)2.0 all those are converted from moin--main--x.x and should be treated read-only.
moin/1.5 is closed, no updates any more
moin/1.6 is closed, no updates any more
moin/1.7 is closed, except for very critical security fixes
moin/1.8 is closed, except for bug and security fixes and rather small tweaks
- moin/1.9 is current release, fixes only, no bigger changes.
for this, we have a bitbucket mirror at https://bitbucket.org/thomaswaldmann/moin-1.9 - so you can fork us there, if you like.
moin/2.0-dev the active main repo used for moin 2.0 development.
for this, we have a bitbucket mirror at https://bitbucket.org/thomaswaldmann/moin-2.0-dev - so you can fork us there, if you like.
Branch and merge early and often. I.e. if you implement a new feature, you can start it in a distinct branch and potentially make it public if you cannot finish it quickly enough.
Tasks for improving developer documentation
Steadily collect infos from MoinMoin wiki pages.
- Start at defining somewhat official APIs.
- Show how to best create URLs (Page.link_to etc.).
- How to use I18N features.
What documentation should go into MoinMaster and what should rather be kept here? Benefit of MoinMaster is that this info gets distributed into every wiki. But I also think it does not make sense to have every developer doc in there? -- ThiloPfennig 2006-12-13 15:11:06
I have seen that some plugins do get outdated in some MoinMoin versions. Would it be possible to define an underlying version number for the APIs? So that rather than that we say: this is a plugin that works in version 1.3 and 1.5 we would say: This plugin works on parser-API version 0.3 ? I mean sometimes nothing changes for some extensions so you can assume that it must work on many different moin versions. Or is it so that one never can say that parts of MoinMoin guarantee to be stable so that you always have to test a plugin before you can say that it works (Well testing is always good). My intention is to make it maybe more simpler to sort extensions. Maybe the version number of MoinMoin does not make much sense? -- ThiloPfennig 2006-12-15 19:01:07