Project management

From FIFE development wiki

Introduction

This article is intended to become the central place to discuss ways to improve FIFE with methods of software engineering and project management.

If you think that your proposal will cause controversy, please add it at the Questions section of the paragraph. The discussion should take place at the talk page of the article.

Backup

Current situation

There is a separte article in place now that covers Backup aspects.

Questions

Proposals

• Try to find a way to create backups of the trac tickets. We could ask cvsdude.com if they could provide us with backups.

Phasing

No phasing planned.

Blog

Current situation

There is a separte article about our developer Blog now.

At the moment the FIFE developer blog gets updated about once a month. The majority of the entries have been written by mvBarracuda though other active developers like Phoku, Jasoka and Mutex did contribute as well.

Questions

Proposals

• Continue to encourage active developers to write blog updates at least once a month.
• There should be at least about one blog update per month written by a project manager to summarize the recent progress.

Phasing

More regular blog updates after the 2008.0 release would be great but our experience has taught us that chances are small that it will happen.

Build systems

Current situation

Currently build system related issues are described at different wiki articles. There is the Build dependencies listing and there are separate guides how to build FIFE on different platforms.

Questions

• Should we describe the different build options at the wiki or simply refer to scons internal build arguments listing (scons -h)? One definite advantage of having a separate wiki article for optional build args and corresponding linker and compiler arguments would be that we could use this information when we add support for new build systems.
• Should we try to improve the current scons build files or add support for new build systems for users who can't get scons working with FIFE for whatever reason there might be?

Proposals

• We should think about a proper structure for build system related articles. ATM it feels somehow unsatisfying but I've got no good idea how to improve it either (yet). So a bit of brainstorming might help.
• What about adding an automated build system that would build the FIFE library every night for each platform? The build manager for that platform would be responsible for the upkeep of the automated build system. GreyGhostNew suggested we look into Buildbot. User:Prock is currently looking into this. The basic order of operations for the automated nightly build would be:
  1. svn update
  2. scons
  3. zip
  4. upload
  5. update page to contain the correct link to the latest builds
• Prock's review of BuildBot

Phasing

No phasing planned. MuteX might consider playing around with BuildBot on his documentation server but for now this got a rather low priority.

Coding standards

Current situation

There is a rather detailed article about our Coding standards in place.

Questions

• Decide if a vim signature should be applied to all cpp & h files. If we decide against it, the vim signatures in place should be removed for consistency reasons!
  • The current vim signature that is featured in some cpp & h files reads: /* vim: set noexpandtab: set shiftwidth=2: set tabstop=2: */

Proposals

• Agree on a commonly used tabwidth.

Phasing

No phasing planned yet.

Communication

Current situation

The Communication article covers communication structures and standards of the development team. We encourage to ask questions, give all kind of feedback and we do especially appreciate (constructive) criticism.

Questions

Proposals

• Identify important hurdles that hinder developers to get started with FIFE. This could be done by interviewing them after they have been on the team for a certain amount of time (e.g. 1-3 weeks.)

Phasing

No phasing planned.

Data structures

Current situation

There is an separate category for Data structures. At the moment the listed articles seem to be up to date.

Questions

Proposals

• The Map Geometry article still covers the old geometry concept of the 2007.1 milestone. Rewrite it for the new concept. The sketches can probably be removed altogether and be replaced with a note to simply use the geometry twister python application to understand the concepts.

Phasing

Decide what to do with Map Geometry article until 2008.0 gets released.

Debugging

Current situation

There is currently no Debugging article whose solely purpose would be to explain how to successfully get FIFE working with a debugger on different platforms.

Questions

• Are separate tools needed to debug the engine side and the scripting extensions?

Proposals

There should be a Debbuging article whose solely purpose is to explain how to successfully get FIFE working with a debugger on different platforms. This article should not describe how to install the debugger and other related steps but simply supply links for these kind of information.

The main focus should be to explain how to actually get the debugger started with FIFE as this might be tricky considering that FIFE doesn't ship as a binary anymore but is now wrapped up with Python.

Supported platforms should be at least:

• Linux: GDB (standalone)
• Linux: Kdevelop (in combination with GDB)
• Macintosh: the XCode debugger
• Windows: GDB (in combination with Code::Blocks or standalone)
• Windows: MSVC debugger

Phasing

These guides should be written as soon as possible. In case we're not able to find developers for certain platforms (likely for Win32 MSVC & Mac) we will need to create tickets for these debugging documentation tasks and try to recruit developers for these tasks as fast as possible.

Dependencies

Current situation

There is a separate Build dependencies article in place. The installation shortcuts section does currently just offer instructions for Debian-based Linux distributions and a small paragraph about Win32.

Questions

Proposals

• Add a CREDITS file to the Subversion repository and add list projects of which we borrow code from. The following structure should be useful:
  • Project name
  • Project URL
  • Borrowed code (short description) & version number
  • Used in these parts of FIFE
• With a CREDITS file in place we could remove paragraphs about borrowed code from the header and implementation files. This should help to keep them clean without giving the impression that we want to hide borrowed code.
• Try to recruit testers who could list the neccessary installation shortcuts for different Linux distributions.

Phasing

Having installation shortcuts for more Linux distributions in place before we release 2007.2 would be nice but can't considered to be a showstopper that would prevent a release.

Developer status pages

Current situation

There is a listing that provides information about almost all developers who are or have been part of the team.

Questions

• Would it be useful to interview FIFE developers who left the team in a survey to identify important reasons why people lose interest in FIFE?

Proposals

Phasing

No phasing planned.

Donations

Current situation

The FIFE team does currently not accept Donations.

Questions

• How is the team feeling about accepting donations?
• What are the advantages, what are the drawbacks?
• How do other open source projects handle this?
• What would we do with donated money if the team would agree on accepting donations?

Proposals

Phasing

Documentation

Current situation

We're already using Doxygen and Epydoc for documentation purposes. These docs get automatically updated on a daily basis as they're hosted on MuteX's development server.

Questions

Proposals

Phasing

No phasing planned.

Engine architecture

Current situation

There are a bunch of engine architecture related articles in place. Architecture Documentation gives a good overview and serves as a starting point to discover the more detailed articles that just cover particular aspects.

Questions

Proposals

• Continue to flesh out the architecture articles. Developers who're actively working on an engine module could document it on the wiki as well.

Phasing

No phasing planned yet.

Forums

Current situation

We've moved to standalone forums. The usual forums activity is rather low (~ 1 new post per day). The majority of the discussions there are development-related but the forums are also a way to stay in contact with the community. It seems to be important to offer a way of persistent community interaction as alternative to the live communication on the IRC channel.

Questions

Proposals

Phasing

No phasing planned yet.

FTP

Current situation

There is an separate article that covers all kind of information that is related to the Developers FTP.

Questions

Proposals

Phasing

Game creation documentation

Current situation

The only article that covers these kind of information is the heavily outdated Game creation guide.

Questions

Proposals

• Completely rework the guide!
• As we want to provide a good starting point for game creators the documentation aspect will be _very_ important for the success of the 2008.0 release.

Phasing

Update the game creation guide as soon as possible after the 2007.2 release.

Getting started guide

Current situation

The Getting started guide appears to be an useful way to introduce new developer into the project without investing too much time into explaining them the basics verbally.

Questions

• How can we further improve the getting started guide?
• What aspects of this project management article should get a paragraph in the getting started article as well? Unit tests seems like an obvious and useful choice but there are prolly a couple of others.

Proposals

• Basically the getting started guide should introduce into all important aspects of the project. Developers who are not willing to invest the time to read through it won't stick to the project in the long run anyway while serious devs do hopefully appreciate the extra information that helps them to wrap their heads around the project.

Phasing

Add paragraphs about important aspects that aren't featured in the article yet (e.g. unit tests) as soon as possible.

Glossary

Current situation

We're already having a central Glossary article in place. However it's not up to date anymore. Here is a list of proposed steps to improve the situation.

Questions

Proposals

• Underline the importance of the glossary for the project and add a paragraph to the getting started guide to ensure that new developers know about it.
• Convince the developers to update the glossary with the 2008.0 release.
• Agree upon what terms should NOT be part of the glossary. A blacklist should hopefully encourage rather heavy use of the glossary in comparision to a whitelist.

Phasing

The glossary should be checked as soon as possible to ensure that the most vital terms are explained there. Furthermore we should try to update it between releases to ensure that the programmers know the basic project terminology to avoid misunderstandings and to ease communication.

IRC

Current situation

• The IRC channel became the hub of our project. Utilizing IRC eases brainstorming, design discussion and communcation in general. While we strongly encourage regular IRC attendance of developers, it's not obligatory for contributors. Full IRC logs are available for developers at MuteX's documentation server.

Questions

Proposals

Phasing

No phasing planned.

License

Current situation

We are currently licensing all of our engine and extensions code under the LGPL 2.1 or newer. That means we give the users the option to decide if they want to use the LGPL 2.1 or if they think a newer version of the GPL would be more suitable for their purposes. LICENSE files can be placed in directories to put the content of these folders under a different license than LGPL 2.1 / newer.

Questions

Proposals

Phasing

Mailing list

Current situation

The mailing list was used as a platform for long term communication and design discussions. However with the rise of the IRC channel and forums-based communication the mailing list lost its former position as main communication platform of the project. Because of a number of problems with the mailing list we decided to send it into hibernation mode and not use it anymore.

Questions

Proposals

Phasing

No phasing needed.

Milestones

Current situation

Milestone planning does currently take solely take place at the corresponding trac page.

Questions

• Would it offer an advantage to create a separate milestone planning category at the wiki to discuss this aspect? In this case the trac roadmap page would serve as collection of tickets but the actual milestone discussion and planning would take place at the wiki.
• How would we avoid redundancy if we use our MediaWiki and trac for milestone planning? The planning itself could take place here at the wiki, however we should still transfer any milestone description updates to trac as well.

Proposals

Phasing

No phasing planned yet.

Misc

Current situation

All questions and proposals that can't be categorized yet should be listed here. Having one place where to list misc ideas is important as they tend to get forgotten if no proper place is found for them immediately.

Questions

• How to cope with the API changes between the guichan releases?

Proposals

Phasing

Mission statement

Current situation

A Mission statement article is in place that explicitly points out the aim of the FIFE project.

Questions

Proposals

Phasing

No phasing planned.

Patches

Current situation

• There is currently only a stub in place that explains how FIFE handles Patches that have been send in by community members.

Questions

Proposals

• Flesh out the Patches article. The article should describe how to send in patches (where to send them to), what the quality standards for patches are and who decides after a review if the patch gets commited to the Subversion repository.

Phasing

The article should be written as soon as possible.

Profiling

Current situation

Although profiling is not that important compared to debugging, especially in the alpha and beta phase where early optimization is considered to be the root of all evil. Nevertheless we should offer our programmers an easy way to perform profiling of FIFE code on every supported platform. Similar to debuggers we can't explain how profiling works in detail and that's not the purpose of such an article. In fact we should explain what profiling tools work well in combination with FIFE and how to set them up to profile FIFE code with them.

Questions

Proposals

Supported platforms should be at least:

• Linux: Callgrind
• Macintosh: ?
• Windows: ?

Phasing

Considering that profiling is an rather uncommon task to normal debugging there is no serious reason to hold back future release for it. In case we're not able to find developers for certain platforms (likely for Win32 & Mac) we will need to create tickets for these profiling documentation tasks and try to recruit developers for these tasks as fast as possible.

Platform support

Current situation

Contributor Alastair checks FreeBSD support occasionally to ensure that it's not broken. There are currently neither active Macintosh nor active Win32 maintainers. The lack of documentation how Debugging, Profiling and working with Unit tests is done on Linux is surely a drawback for trying to recruit maintainers for other platforms as well. Reference documentation for Linux could serve as starting point for documenting these aspects for other platforms.

Questions

Proposals

• We should try to recruit maintainers who could ensure that the following platforms are working:
  • FreeBSD
  • Macintosh (Xcode)
  • Win32 Code::Blocks / MinGW
  • Win32 MSVC
• Linux maintainers are possible but not really needed as the majority of the active programmers are already running Linux-based distros.

Phasing

It would be useful to find at least willing testers for the platforms mentioned above before we ship the 2008.0 release. Nevertheless finding longtime maintainers for these platforms should be our aim in the in long run.

Project management

Current situation

As this article does focus on project management itself, this part of it can be seen as a meta paragraph to ask questions and bring up proposals about the project management itself.

Questions

Proposals

Here is a list of project management tasks that have a high priority:

1. Island_demo planning.
2. Debugging documentation.
3. Profiling documentation.

Phasing

Focus on the island_demo planning for now but we should especially try to come up with debugging documentation as soon as the island_demo planning phase is over.

Public relations

Current situation

A Public relations article is slowly evolving. A whole set of information is stored there: forums threads, news coverage, events FIFE developers plan to attend, a tally to analyze where advertisement works out as well as a section for interviews with FIFE developers. A first draft for a basic code of bevahiour has been fleshed out.

Questions

• Should recruitment threads be listed at the Public relations or at the Recruitment article?
• Should we change the meaning of the FIFE letters to reflect that we have moved away from our Fallout roots and that we're aiming to offer a general 2D game creation framework now?
  • How about "FIFE - the flexible isometric free engine"?

Proposals

• Add FIFE to this game development library listing: http://www.twilightsembrace.com/personal/gamelibs.php
• Arrange an interview with RPGcodex after 2008.0 got released.
• Improve our wikipedia article to better reflect the current status and the aims of the project. This is dependent on the Mission statement. An example for a better similar article is the one about GemRB. The article could feature:
  • A screenshot of the upcoming 2008.0 techdemo.
  • Our mission statement.
  • What FIFE wants to be and what FIFE does NOT want to be.
• Create a new article that serves as place for collecting Release feedback.

Phasing

No phasing planned yet.

Recruitment

Current situation

The Help wanted article does currently cover positions that are open and should be filled.

Questions

• Should recruitment threads be listed at the Public relations or at the Recruitment article?

Proposals

• Come up with descriptions for "smaller" jobs:
  • General wiki worker (e.g. improving the Game creation guide)
  • Tester (platform specific)
  • Release manager / maintainer (platform specific)
• Create a help wanted template that just needs to get modified for different forums (because of different tags, bbcode, images not allowed, etc.). This way we could try to get recruitment managers involved who would just need to post the customized template at different forums to disburden mvBarracuda :-)
• Try to recruit a Mac maintainer again.

Phasing

No phasing planned yet.

Release packaging

Current situation

At the moment there is only a small stub article about Release packaging. Considering that we want to disburden the currently involved developers it seems important to work out such guides so that we could try to recruit release managers for FIFE later who could focus their efforts on packaging releases and keep the corresponding documents up to date.

Questions

• Should we offer precompiled linux binaries?

Proposals

• Flesh out the Release packaging article with easy to follow steps how FIFE should be packaged for all supported platforms (Linux, Mac, Win32).
• For Win32 we should reach an agreement if we should ship releases with MSVC or with MinGW binaries.
• The guides should not only describe how to package official milestones but also SVN snapshots and all kind of Software development kits.
• We should reach an agreement how to automatically or at least semi-automatically generate READMEs for releases. Possible options would be to have templates for READMEs that just need to be filled in with some additional information by the release managers. Or we could extract the most vital information from the trac milestone planning tool and add this to the corresponding release README.
• Try to get release managers involved in the project who could package the releases based on the initially created documents and who would be responsible for keeping these docs up to date together with the other developers.
• Rule of thumb: try to automate or semi-automate as many steps as possible to disburden developers. This can be achieved by having scripts that download the neccessary files from SVN, build FIFE and run the unit tests, delete temporary files after that and create a README skeleton that just needs to be filled with actual information in rather few places.

Phasing

No phasing planned.

Requirements analysis

Current situation

There is currently no separate article that describes how the FIFE team handles Requirements analysis. However there is an article on Requirements in special that have been found via extracting them from Use Cases. Furthermore there is a separate article for use cases of the island_demo game.

Questions

Proposals

• Requirements analysis should be based on Use Cases.

Phasing

No phasing planned.

Software development kits

Current situation

There is a separate article that covers the Win32 compile SDK with emphasis on the following aspects:

• Planned changes for the next release of the SDK and why these changes are useful or even needed.
• Version history of the SDK. What SDK works for which SVN revisions.
• Featured software (including version numbers) for the different SDK releases.

Questions

• Would it be useful to offer a Mac equivalent of the SDK that we're already providing for Win32 users? Would this ease building FIFE on Macs?

Proposals

Phasing

A new compile SDK should get released together with the 2008.0 release.

Subversion repository

Current situation

There is a separate Subversion repository article that covers the majority of SVN-related aspects. A new paragraph about SVN guidelines is in place now as well.

Questions

Proposals

• Describe common SVN tasks for TortoiseSVN users as well.

Phasing

No phasing planned.

Techdemo

Current situation

The FIFE development team decided to revive the island_demo idea and does currently work on an example game that is based on this concept.

Questions

Proposals

Phasing

Finish island_demo planning (moving all tasks from wiki to trac tickets) before the current SVN trunk gets released as 2008.0 milestone.

Ticketing system

Current situation

Trac tickets are often use by now; especially in comparision to the start of the project the awareness of the importance of working with trac ticket was rather low. However there is still room for improvement.

Questions

Proposals

• Split large tasks into several smaller tickets to ensure that interested volunteers could tackle this step by step.
• Tickets should be created for all tasks. This this is a rule of thumb that does not apply to very small tasks that can be coordinated with IRC communication and can be tackled within a short amount of time (not longer than one day!).

Phasing

Create tickets for all tasks that are listed at the Island_demo article before 2008.0 gets released.

UML

Current situation

There is no currently no article that describes how the development team utilizes the Unified modeling language (UML) for FIFE.

Questions

• Is creating UML diagrammes for all the modules of the Engine Core worth the work?
• Should developers be encouraged to draft especially larger refactorings via UML diagrammes first?

Proposals

• If we decide to create UML diagrammes for the different engine core modules, the diagrammes themselves should not only be shown at the wiki but the Dia source files should be also commited to SVN. Developers could use these diagrammes for planned refactorings as well. This way they could rather easily provide graphical drafts of their planned changes.

Phasing

High level UML diagrammes for the engine modules shot get created while these modules get documented at the wiki.

Unit tests

Current situation

At the moment there is only a stub that describes how FIFE handles Unit tests.

Questions

Proposals

• Stick to unit tests as a way to test releases in a fast and reliable way. This should help to reduce the time we do currently spend to manually test milestones before releasing them.
• Create documentation how to run the unit tests on the different supported platforms and how to create new ones. This includes adding short notes about the used unit tests frameworks for the engine as well as for the extension side.
• There should be a separate article for Unit tests. However either the Getting started guide OR the coding standards OR both should refer to this separate article to raise the awareness for the importance of the unit tests.

Phasing

The project managers should raise the awareness for the importance of unit test documentation.

Use cases

Current situation

The team has written down a small number of Use Cases to identify requirements for the scripting API as well as the engine side. Furthermore there are now special Techdemo:UseCases in place.

Questions

Proposals

• Stick to writing use cases as the prefered way of Requirements analysis.

Phasing

No phasing planned.

Website

Current situation

FIFEngine.de is the home of the FIFE project. The main page contains news about the project that often are just summarizations of developer blog posts. The forums are directly integrated into the Website but the project wiki is a separate instance and therefore you'll need to register at the wiki as well if you plan to contribute to the articles here.

Questions

Proposals

• Work out a plan for a completely redesigned Website.

Phasing

No phasing planned.

Wiki

Current situation

The wiki is used as persistent medium for project documentation.

Questions

• What articles should be linked to at the wiki frontpage? What articles should NOT be featured on the frontpage and rather be part of categories (that are featured at the frontpage).

Proposals

• Similar to the idea of creating a module design first, it's worth thinking about the structure of new wiki articles before you actually start to write down the content of the article. Having a structure skeleton for articles in place helps to direct ideas of wiki contributors to the right article. With a structure in place contributors are encouraged to fill the existing skeleton.
• Create a seperate Wiki articles that covers the following aspects:
  • What content should be stored at the wiki?
  • What content should be NOT stored at the wiki?
  • What guidelines exist for creating new articles?
  • When should articles or talk pages get signed by developers, when is it better to depersonalize discussions?

Phasing

No phasing planned.