[Box Backup] Wiki migration

[Martin Ebourne]

On Sat, 2006-11-25 at 16:57 +0000, Stuart Hickinbottom wrote:
> I think I've now managed to complete that (thanks to James for his help
> along the way). For reference the wiki main page is here:
> 
> http://bbdev.fluffy.co.uk/trac/wiki
> 
> I've made the old wiki point to this new one on the main page (the old main
> page is still available there if anyone needs it).
> 
> Along the way I've done quite a bit of spring cleaning of the pages, plus a
> small about of restructuring; hopefully that will make the wiki easier to
> navigate for users in particular.

Fantastic work Stuart, thank you very much! I've had a good look through
and I think that is a big improvement. A minor comment is that I feel
the front page should be a little simpler, though I didn't have any good
ideas on how to do that and it's certainly not excessive as it is.

> I think there is room for improvement, though. Enhancements and known
> problems should be tracked through tickets rather than on wiki pages, and
> more use should be made of milestones. This allows a problem/idea history to
> be properly tracked through raising, discussion, implementation and release.
> Creating a lot more tickets won't necessarily create more tickets than can
> be easily understood since they're only tabled for a release when a
> developer picks one of them up and is assigned it.

Problems and planned enhancements are being tracked through tickets,
it's just that trac has only recently been available for Box, so there's
a lot of stuff that was in the wiki in the interim. Certainly any bugs
mentioned in wiki pages should be moved to trac tickets (unless already
resolved). Check on the dev mailing list if not sure.

As for creating tickets for enhancements, the plan is only create the
ticket where there is a genuine intent to add the feature (or if it has
already been developed and a patch is available). This pretty much means
that enhancement tickets can be created by anyone, provided they include
a patch to implement it. Planned but unimplemented features should be
created as task tickets and only developers should be doing this.

The reasoning is that otherwise a lot of useless tickets end up getting
created for random feature requests that will never get implemented,
either because they don't fit in with the goals of the project, or just
because no-one will ever spend the time on them. When this happens it
doesn't really benefit anyone.

Cheers,

Martin.