Developer Role

Introduction

Development for SimSig is a privilege, not a right, and certain expectations are made of you. That said, we appreciate a good simulation that expands the SimSig range of products.

Each time a developer wishes to start a new simulation, permission must be sought from an Administrator. They will ensure that area has not been allocated to somebody else, and that your workload is not too high. Generally only two to three simulations may be in development by one developer at a time (prior to release).

An agreement will be provided for the developer to electronically sign. This sets out the expectations as follows:

The sim shall reach beta testing status within one year of starting for large simulations, nine months for medium simulations, and six months for small simulations.
Developers shall coordinate with an administrator or project manager for beta testing, with a realistic estimate of when it will be ready.
What happens if the deadline is not met, and is not extended? The developer may choose to hand over the data to another developer, in which case a portion of the profits will be retained, or development may be abandoned in which case any development for the same area will start from scratch and the original developer gets nothing. If the developer does not agree with the administrator then another administrator will cast the deciding vote.

The size (small/medium/large) shall be agreed by the developer and administrator at development start, but may be altered later if both agree. This simulation size also dictates the release price. Factors to determine simulation size include:

Number of panels/workstations (a single panel/workstation is likely to be a small simulation)
Whether ARS is provided (may make the simulation easier)
Whether level crossings dominate (may make the simulation more difficult)
Whether absolute block is simulated (may make the simulation more difficult)

Simulation Phases

A simulation goes through three main phases:

Alpha - developer is still developing the sim, but alpha testers get to see it in development, offer critique as it grows, and perform basic testing.
Beta - by now the simulation should be virtually ready for release, with little to no Mantis tickets outstanding. The manual should be written, ground frame pictures should be complete, splash screens should be provided, and timetables should be complete. Beta testers see the sim for the first time.
Release - the simulation is released. The simulation is under maintenance now.

If beta testers find a large number of bugs then the simulation will revert back to alpha testing. The threshold for this is any of following:

25 or more Mantis tickets with a severity of "minor" or lesser severity
3 or more Mantis tickets with a severity of "major"
1 or more Mantis tickets with a severity of "crash" or "block"

In addition, if a significant change to the simulation is made while beta testing, such as adding a new signalling area, or adding ARS where previously it did not have ARS, or an era is added/removed, then the simulation will revert to alpha testing.

If a simulation reverts to alpha testing, the same beta testers can re-test the simulation when the simulation returns to beta testing.

Expectations of a Developer

Developers are expected to use the Developer forum for data questions. Administrators should not be singled out for questions. This includes foreign development as >95% of the data is not geo-specific.

[See Tester Roles for full details] For the smallest to medium size simulations, Developers may nominate up to six testers for alpha testing, and up to six testers for beta testing. No more than two other developers, not including the simulation developer, should form part of those twelve. Each tester must have been previously approved (they will have the Tester role listed in their public profile). Tester licenses can no longer be issued to users without that Tester role.

For large to extra large simulations, Developers may nominate up to seven testers for alpha testing, and seven testers for beta testing. No more than three other developers, not including the simulation developer, should form part of those fourteen.

Two administrators, or one developer plus the simulation developer, may agree to grant more tester licenses in exceptional circumstances.

Respect others' opinions, even if they do not match your own. If a stalemate is reached over how a subjective issue should be resolved, the opinion of two other developers should be sought.

Mantis Severities

SimSig uses the standard Mantis definitions for ticket severities. Testers should categorise a ticket in the following way:

Trivial - ambivalent whether this gets done or not (subjective; not a fault)
Minor - a bug or non-compliance (eg Style Guide) which should be fixed
Major - a bug which prevents something significant from working, such as an entire branch line
Crash - the simulation is basically unusable

Examples:

A yard slot isn't working. This would be a "minor" as it's a fault, but not one that prevents the sim being tested generally
Trains hit "buffers" on a running line. This prevents testing of anything beyond the buffers, so should be classified as "major"
Gradient data is missing from a large chunk of the simulation which should clearly have it. This creates inaccurate testing so should be classified as "major".
Chaining data is missing or won't hand over trains properly to a released simulation. It's unusable for chaining so should be classified as "major". If trains hand over with TDs but there is a display issue then it could be a "minor".

Mantis Tips

Testers have their own set of tips for how to report issues and questions but here are some for developers:

If you reject a ticket, add an explanation as to why it's been rejected
Do not close tickets yourself (unless you raised it)
Use Mantis for TODO lists. It helps testers see, and avoids reporting, known issues.
If a ticket is resolved, use the "Fixed in version" field. Don't add a note stating simply that it's been fixed as that is no use to anybody and probably won't even be seen.

User Manual

Use the User Manual template, either the single page version for smaller simulations, or the multi-page version for larger simulations. All user manuals will now be on simsig.co.uk, no exceptions All manuals are now locked against modification by normal users.

You don't need to write the manual yourself, but no other developer or administrator is going to either. But you must ensure it is accurate.

The user manual must be ready before beta testing commences.

GIT

The SimSig GIT must be used for version control. No exceptions.

Data with a check-in comment or label of V1.0 must be committed prior to release. The first public release of a simulation shall be 1.0 (major.minor). Subsequent releases must increment the minor number, skipping any number ending in zero(es) such as 10, 200, etc. The build version shall not be used for public releases. A major version number increment should be considered for breaking changes, such as a chunk of simulation added.

Maintenance

Once a simulation has been released, the developer is expected to be available to fix bugs according to the following schedule:

1. In the first 7 days minor bugs must be fixed by a re-release date of 7 days after the initial release.

2. In the first 7 days major or more severe bugs must be fixed within 24 hours of the bug being raised.

3. A second re-release is due by release+21 days, assuming minor or more severe bugs exist

4. A third re-release is due by release+60 days, assuming minor or more severe bugs remain

5. Any minor or more severe bugs found after the third release are expected to be fixed within 30 days. The developer may lower the severity with the agreement of either the reporter or an administrator. The reporter or administrator should add a note to the ticket indicating an agreement to regrade the severity.

Any failure to address major bugs within the above timescales will result in another developer, nominated by an administrator, will attempt to step-in and fix those issues. Failure to maintain after such an episode will result in a review by two administrators who will decide whether to hand over the simulation to another developer. Profits will then be adjusted according to the result of that review which will take into account the work done by the new developer.

Sims in Development

At the time of signing the Developer agreement, a developer may have one or more sims already in development, and one or more sims already released. Where this is the case, the following applies and overrules anything above:

Released simulations are unaffected by maintenance points 1 to 4, but point 5 will be in effect, with the time period starting at the time of signing.

In-development simulations are expected to be finished within one year (large) or six months (smaller) [per comments near the top] from the date of signing the agreement.

Developers who choose not to sign the agreement will relinquish their developer role for that simulation. What happens to that data is up to the developer:

The developer can choose to withdraw their data. Administrators may allocate the area to another developer, but that developer will start from anew. The previous developer can claim no rights to monies, copyright, or design.
The developer can choose to hand over their data. An agreement will be made between the previous developer, an administrator, and a future developer as to distribution of income for that simulation. The copyright will be split, and the previous developer may indicate
preferences for design.

Succession Planning

If a developer chooses to leave, they will continue to receive their income, subject to the conditions in the Maintenance section of this page.

If a developer passes away after release of a simulation, their income may be directed towards a nominated person. The administrators should be emailed the name of the person and their contact details. It is up to the developer to maintain this information. Maintenance of the simulation may be transferred to another developer, per the Maintenance section in this page.

If a developer passes away before release of a simulation, and the Git repository has data for that simulation (including research notes), then the administrators may nominate a new developer. Again, the income would be divided per the Maintenance section in this page.

Last edited by GeoffM on 27/02/2019 at 17:58