ProjectOverview

Introduction

This is an overview of the Foswiki development and release processes, without getting into the dirty details. Links in the text will lead you to those details when you are ready.

Foswiki is a highly democratic project. There is no fixed project management team who are going to tell you what to do. Even the "development team" is an abstract concept, with a constantly shifting cast of members. Success of the project is based on:

1. being able to trust contributors to do the best job they can,
2. everyone engaging with the processes, even when they may not agree 100% with everything that is done,
3. people taking action when they see something that needs doing, or correcting.

Many of the people who have worked on Foswiki over the years are highly experienced and knowledgeable, and their contributions have helped to shape the development and release processes we use. They aren't perfect (what process is?) but they work pretty well.

Terms and concepts you should be familiar with before reading further:

• Requirements management
• Process
• Version control
• Continuous integration

Requirements Management

The requirements management process in Foswiki is driven by users, who propose new features, and developers, who drive improvements that have may have no visible effect on end users.

Everything we do in Foswiki is ultimately driven by feature requests. These can take two forms:

1. requests (or proposals) for enhancements and major changes follow the release process. There are guidelines covering how a feature gets developed, but the essence is that if you make a feature request, it's up to you to follow the process, find the resources and get the work done.
2. requests for bug fixes or very minor enhancements are handled using tasks.

Eventually any feature request translates into one or more tasks in the Tasks web. These tasks are used to track the development, and provide a concise history of changes.

In both cases, it's essential that the proposer remains engaged with the request through its life cycle. In general, the project does not respond well to feature requests that are "thrown over the wall". Experiences indicates that these are usually poorly thought out, poorly specified, or do not fit well within the existing code. Following the features process demonstrates commitment, ensures that experienced community members have a chance to comment. and engages other potential contributors.

Development

Development isn't just about writing code. Development also covers activities such as writing documentation, building infrastructure, designing skins - even writing this page is development.

However in practice, we divide development into two classes; stuff that gets checked in and stuff that is not checked in. We'll talk about the latter first, as the processes are very simple.

Stuff that is not checked in

This class of development covers anything that doesn't directly participate in the Foswiki release process, and the process is much less formal. For the most part, these developments are either conducted in this site, or end up here in one form or another, so it's worth saying a bit about how the site works.

The developer will be interested mainly in five webs on the site:

• Support
  • The Support web is where questions are raised and answered, and we maintain a bunch of supplementary documentation. Anyone can raise and answer questions, and anyone can contribute supplementary documentation.
• Community
  • This is a largely unstructured, informal collaboration site covering community aspects of Foswiki. Here you'll find meeting minutes, marketing communications, and random community-related discussions.
• Development (this web)
  • This web serves two main purposes; first, it is where ideas are brainstormed and feature requests are raised and discussed. Second, it serves as the repository of developer-biased documentation that is too detailed for general users.
• Tasks
  • The Tasks web is the beating heart of Foswiki development. It is used strictly for the Tasks wiki-application, which is used to track actions performed in the project. The process used here is formal, and documented within the web itself.
• Extensions
  • The Extensions web is the home of all uploaded contributions. At the time of writing this web is in flux, but it will always be highly structured (and mostly automated), acting as an index and download site for community extensions.

Stuff that gets checked in

By this we mean anything that is added to version control. This class again divides in two, this time into:

• Extensions
  • These are community contributions - plugins, skins etc. - that have not been adopted into a core release, but have to be downloaded separately.
• Core
  • This is everything that ultimately participates in the generation of the package that end users download.

There is a wealth of information covering the details of how we go about development, including details of how we use version control tools, so we'll restrict ourselves here to a simple overview of how the source code repository is organised.

The Foswiki source code control uses a shared repository model (as against the other more populist model, fork and pull). Developers ask to be allowed to check in, and once they are granted access (subject to peer approval), are all able to push changes into the repository. There is no formal checkin gate. All changes are automatically mailed out to registered developers, allowing a continuous inspection of code changes by the whole community. The trunk branch is continuously tested by running unit tests to ensure correct functionality, and also runs the trunk.foswiki.org site for more informal testing. The trunk branch represents the bleeding edge of development.

Extensions

Extensions (at least, those that are not part of a core release) live permanently in the trunk branch. Extension developers may choose to branch or tag their extension code, but in the spirit of "don't tie me down", there is no mandatory process as there is for the core.

Core

Of necessity the core has a rather more formal process.

When we decide to do a release (a decision made by community consensus) then the release team creates a release branch, which is named the same as the release. This release branch is effectively frozen, and only changes that fix bugs are permitted - no new features may be added, though bugfixes, translations, and documentation are encouraged. Release branches are also continuously unit tested. An example release branch name is Release01x01 indicating that it covers Foswiki releases 1.1.0 through 1.1.n

When we are actually ready to make a release, then we tag the release branch with a patch number, starting at 0. For example, the Release01x01x03 tag identifies the sources used to build the Foswiki 1.1.3 release. Once a tag has been applied, the sources that it tags may not be modified by anyone.

The release team is the ultimate authority that decides whether something gets released or not. However in the spirit of democratic, community-driven development, the decisions of this team are made in full public view, and decisions very rarely run counter to the consensus.

Other important processes

• security alerts.