It's better when it's simple

User Tools

Site Tools


Release Management Team

The Release Management Team, as the name suggests, takes care of organizing the whole release process and prepare the release packages.

What skills are needed?

  • Communication and Organization skills to organize the joined efforts of all teams during a release
  • Some knowledge about git
  • Knowledge about writing shellscripts (to automate build tasks) might help

What are the main Tasks?

  • keep track and manage feature deprecation processes
  • initiate releases
  • create release plans and deadlines
  • prepare todo lists
  • handle releases

Who are we?

Adrian Lang from Berlin
I would like to coordinate the release team and take substantial part in the work we have to do.
Guy Brand from Strasbourg
I'd gladly take over a part of the needed work in the release team.
Andreas Gohr from Berlin
I handle things that need access to the DokuWiki server and of course help with setting up the team. I'd love to leave the management of the team to someone else though.

Current Tasks

  • make a definite release plan and do the release of “Lazy Sunday”
  • managing DokuWiki on a stick? Are there any other public derivatives of DokuWiki? ICKEWiki? At least coordinate derivatives
  • should we make the downloader official?
  • Handling Plugin-Wizard?

Suggestion for Dokuwiki Release documentation

Here's how the Zimbra people do it:

They use bugzilla for bugs and feature requests. These bugs are assigned to (or taken by, I don't know) people responsible for solving the bug or planning the implementation of the feature request. A bug is confirmed through testing, then in development, than resolved as fixed or unfixable or worksforme and then verified (through their QA-department). A feature request is taken into account by counting votes for it. The head of development takes a look at the feature requests with the most votes and this feature gets a higher priority than other features.

All finished bugs are targeted to the next release.

After some time it's feature-freeze time and all feature requests “in progress” are targeted to the next release. Then the plan for the next release (beta, beta2, beta3, rc1, rc2, GA) is made. If a feature request “in progress” cannot be finished, it's slotted to the next release.

When the Zimbra release team thinks, “it's right”, the beta phase is exited into the release candidate-phase, where only bugs are squashed, no feature is altered or added.

After some time, the release gets GA (globally available) and makes it to the download page.

Now something brilliant: They have this product management site (, that queries the bugzilla and automatically shows finished bugs, embedded feature requests etc. and thus creates the changelog. Important changes (like the ones Andi marked in his changelogs) are then transported to an official PDF-document available on downloading the release.

I think, that this bug and release management is brilliant, productive and very professional and we should follow that as a guideline. I don't know my way around github's bug management that well. Perhaps someone could answer, if the described bug management and this product management site could be possible using github.

If not, we could move the bug managment to bugzilla (or whatever else, Mantis comes to mind…) and speak with the guys of the admin team about it. (Hey! Just remembered, I'm one of them :) )

– Dennis Ploeger, 2010-10-07 20:24

Bummer! Somehow I forgot, that you people are working with flyspray. Sorry. So, what about actively using the release planning feature of flyspray?

– Dennis Ploeger, 2010-10-08 07:35

Actually, we are using it:, just currently there are no open tasks. — adrianlang 2010/10/08 09:53
teams/release.txt · Last modified: 2020-11-22 07:00 by Aleksandr

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki