Contributing to Slash'EM

Introduction

Slash'EM is the game it is today because many people have helped to
develop it. Some in large ways and others in small ways. Both kinds
of contributions are vital to the life of a game like Slash'EM. This
page aims to tell you how to contribute in small ways and provides some
pointers for those who would like to make a larger contribution.

It is a sad fact that the dev-team do not have as much time to play Slash'EM
as they would like. It is therefore very important that when we consider
whether a proposed change to Slash'EM is beneficial or harmful to the
game we hear the views of players as well as programmers.

Please consider joining the slashem-devel mailing list and partaking in
discussions. Your opinions and your votes can help to make Slash'EM a better
game.

Another thing that the dev-team don't spend enough time doing is testing.
This is especially important during the alpha phase of development when we
need people to test the game who aren't going to be upset that they've just
lost a really promising game due to some stupid bug. We would also value
input during beta-testing since we have found that many people don't bother
to report bugs assuming that we must already know about the problem.
In truth, if a bug is not listed in the bug tracker, we almost certainly
don't know about it.

If you are planning to test Slash'EM under UNIX then it will help if you
can configure the game to work without any privileges. We don't normally
recommend this type of configuration because it provides no defence against
cheating on a multi-user system but it has the great advantage that UNIX
will generate core files on segmentation violations and the like.

If you do find a bug then we would be very grateful if you could include
the following pieces of information in the bug report:

The version of Slash'EM you were playing (and, for CVS, the date that
you checked the files out).

If you are using a binary compiled by somebody else, where you got it from.

If you know how to repeat the problem, then detailed instructions on how
to do so.

If you don't know how to repeat it, then give as much background to what
you were doing at the time so we can begin to get a picture.

As much information about what happened as you can remember (cut and paste
messages from the game is even better).

Any entry in the panic log.

If a panic savefile was created, or the level files are still present then
include these as well.

We often find that we have bugs logged which have been there for a long
time. It is very helpful to have confirmation that the bug is still present
in a recent version and even better to get clues to what circumstances might
trigger the problem.

If you would like to fix a bug in Slash'EM then please choose one of the
unassigned bugs from
the bugtracker
and drop a line to the slashem-devel mailing list to ask a member of the
dev-team to assign the bug to you. If the bug is something that you have
found which hasn't yet been reported then please submit a bug report via
the bugtracker first.

Once the bug has been assigned to you, you can be confident that no one
else will be working on it. The first step to fixing a bug is to get the
source for Slash'EM. You can use the latest source tarball. Even better is
to use CVS to get
a copy of the latest source.

Once you think you have fixed the problem, create a diff against the
Slash'EM source that you were working from. Ideally, this should be in
unified diff format taken from the top of the Slash'EM directory tree.
For example, you might work as follows:

Then after making any necessary changes to the files in the slashem
directory, building the game and testing it, you can create a patch as follows:

% cd cvs/slashem
% cvs -z3 -Q diff -u > ../patch.diff

You should review the patch to ensure that all the changes you made are
included and the make sure that no other changes have been included (eg.,
debugging output). Once you are happy with your patch send it to the
slashem-devel mailing list for review.

We recognise that, having submitted your patch, you will be very eager
to hear back from the dev-team. We do try and review patches submitted to
slashem-devel in a timely fashion, but please bear with us if it takes
longer than you might hope. Sadly we cannot always give as much time to
Slash'EM as we might like to. Your understanding is appreciated.

Once your patch has been reviewed, it will either be returned to you
for further work if that seems appropriate or committed to the CVS
repository by a member of the dev-team. The dev-team member will also
create an entry in readme.txt listing the bug as fixed and giving you
credit for your work. It is easier if you don't include this change in
your patch since it is likely to introduce conflicts which need to be
resolved manually. You can now sit back and bask in the glory of having
make your first contribution to Slash'EM.

If you have an idea for a new feature for Slash'EM (or an improvement
for an old one) and you are prepared to implement it then you can propose
it on the slashem-devel mailing list. This isn't the only way that new
features get added to Slash'EM, you can also simply write and publish
a patch. If it proves popular, we may decide to include it (or a modified
version of it) in the next version. If you have a great idea, but aren't
able to implement it, then please submit a feature request instead.
The slashem-devel mailing list is not the place to propose that other
people implement your idea, however good it is. Of course, if you have
already found somebody who is prepared to do the implementation, then
that's quite a different matter.

You might like to base your proposal on the following model:

Explain what the game currently does.

Explain why you're not happy with this.

Explain in as much detail as possible how you propose it should behave.

Explain what consequences this might have on game balance.

If you decide you'd like to propose more than one change then you
will need to consider whether to make one proposal or several.
Ideally they should be several proposals if they are independent
of each other and one if they need to be considered as a whole.
With several proposals it's worth spacing them out a bit so that
we don't get confused.

Send your proposal to the slashem-devel mailing list and wait. Chances
are that you won't get any replies (which hopefully means that no-one objects).
Allow a couple of weeks just in case and then submit the patch to the patch
tracker.

There are also a number of jobs that you will need to join the dev-team
to do. These include the following:

Triage. This is the process of reviewing bug reports as they are received;
closing duplicate reports, making sure we have the information we need and
requesting it if not, attempting to reproduce the problem and assigning
priorities.

Quality manager. This is the process of setting milestones for bugs,
deciding when we are ready to make a release and guiding a version of
Slash'EM through the development cycle.

Publicity. We need someone who is good at writing prose to keep the
various websites up to date and to issue announcements etc.

Packager. We already have people who package official binaries for
a number of platforms, but there are many more platforms that no-one
currently supports. We would also expect you to fix problems reported
against your chosen platform and to respond to support requests relating
to that platform.

Release technician. It takes about a day to release a new version of
Slash'EM which is time that could be used to fix bugs. If you more comfortable
with the UNIX command line than programming, then this could be the job for you.
There are some notes available about how this is
done.

The Slash'EM dev-team is not some elite group which is particularly difficult
to join but we do ask volunteers to prove themselves before they join. In our
view, this will delay a serious applicant only very slightly while avoiding
the problems of accepting people onto the dev-team who then don't actually
do anything, or perhaps worse, allow their enthusiasm to overtake their
abilities.

If you would like to join the dev-team, please take the time to demonstrate
your ability to do the task you would like to take responsibility for and
your commitment to Slash'EM by helping from outside the dev-team until you
have some sort of track record. As a guide, this might take a couple of months,
or longer if you have less free time available to give. Note: We are only too
aware of the difficulties of combining Slash'EM with a busy life. Please do
not feel that there is any requirement to invest a certain amount of each
week or even of each month. Many of us are only able to give a small amount
of time too!