The future of Deviation

Let me start off by saying I have no plans to stop working on Deviation, and that I am committed to keeping the site up and running.

That said, I haven't done much work on Deviation in the past year, and when I have done, it hasn't been for a long period of time. Given that we have a reasonably active community here, I don't want to stand in the way of progress if possible.

So I'm looking for suggestions on the areas of interest:
1) The forums. FDR does a good job around here, keeping things running, but we may be in the market for a 2nd admin to help out. If you are interested you can PM me, but only long-standing members need apply.

2) The code. I am aware that there has been development work in the deviationtx branch, but releases from there aren't on the main-site download links, so only those who spend time in the forums may be aware of it. When I was gone for a while in 2013, rbe had the same issue. I'd like to find a better permanent fix for this.

3) Tickets. The tickets have gotten out of hand since I don't look at them much. I'd like to find a way to manage them better. Maybe by having a single 'group' repo with an expanded admin list, or separating the tickets from the code (I have played with using redmine as the ticket system and allowing filing tickets directly from the forum. Sadly, my hosting provider doesn't provide a recent-enough Ruby installation to make that very viable)

4) Documentation. Documentation tends to get out of date quickly when active development is going on. We've discussed switching to a Wiki in the past, but I like having documentation versions with the releases. I don't know if it is possible to snapshot a Wiki into a pdf (and have it actually be useful)

5) Multi-module stuff. I have no idea what is going on with this one, but it is the most-likely aspect that I will tackle myself since I think we're very close to a workable solution.

Anyhow, while the community here is active, I don't expect that there is enough expertise/desire here to address all of these issues. However, maybe solving just a couple critical ones will be enough. I'm open to any ideas any of you may have.

At least I personally don't (usually) commit changes that I think are broken. When making big changes (like the GUI changes for 4.0) that is bound to happen, but it is not generally my intent. So releases have a value in that I generally stop development and only do bug fixes before a release. This helps to give confidence to a user who doesn't follow the forums religiously that it is unlikely to crash his model. So I believe releases are valuable for those users.

I haven't given this a lot of thought, but until I am willing to fully hand the reigns over, I do not think I'm likely to give control of features and releases to a committee. We have had great work done by folks like suvsuv and rbe2012 which I decided to not include or do differently (and please note this has nothing to do with the quality of their work, just that it didn't go in the direction I wanted to go in). I haven't looked too much at the latest progress, and can't speak to whether it would be to my liking.

So my thoughts at the moment go something like this:
1) maintain a master code branch that i am responsible for. Either by permission or by agreement, no changes go here without my approval
2) maintain a branch of the the last official release. This can be open to trusted developers who agree to only do bug-fixes on the branch
3) maintain a development branch that is open to trusted developers. new features can be placed here without any consultation from me, and when I'm doing development I would likely develop here. When getting ready to do a release, code will be pulled from here (or not) into the master branch for release, but that may happen infrequently.

We can setup a build daemon to build from (2) and (3) automatically (there is probably no point in auto-building from (1) with links in the download section. In the case I go AWOL for too long, and a good-faith attempt to reach me fails, the group would have the proper access permissions to make new releases from (1)

This isn't easy to do with a single repo without just trusting developers to do the right thing. I am not sure if I am there yet. So I may decide to keep 2 bitbucket repos, one for official releases and one for development and bugfixes (on a branch).

That would leave the issue tracker which really needs more users to help out. I'd like to tie the tracker to the actively developed repo so that tickets can be auto-updated. The bitbucket tracker is really limited in capabilities, but I think it may be possible to import tickets from one repo to another.

Again, this is mainly my thoughts as they are at the moment. It isn't a decision, just my current ideas.

I don't know if that really solves the issue. We could already convert odt into html if we wanted to. The problem is that it isn't editable online. The only reason for moving to a wiki is to make it easier to update online, which means I either need a custom wiki software, or stick with the languages supported by wiki software (I think the bitbucket wiki supports markdown)

Wiki syntax tends to be quite limited compared to a full word-processor, I think it would be difficult to write the documentation in markup and convert it into a good-quality pdf, but I am not familiar with Sphinx, and perhaps I'm wrong.

The other discussion we've had is to use google-docs for the documentation, but honestly, I don't think that would help much, as I don't think it would help documentation get written more quickly.

Also remember that the documentation often gets translated into other languages, and we need to continue to keep that as easy as possible to do.

In the end the only purpose would be to increase the number of people who contribute to the documentation, and I'm not sure there is anything that would really do that

I've given it more thought, and here's what I'm thinking:
a) we'll move the official repo to the deviationtx group repo. I checked and it is possible to restrict access on certain branches, so I may create and restrict a 'staging' branch for preparing for releases.

b) I'll shut down the bitbucket bug tracker, and replace it with a self-hosted version. The primary reason for this is that I want to require all tickets be created by registered users (because anonymous users never respond to tickets), but DO NOT want to require users to create bitbucket accounts. By self-hosting, I can use single-signon so your forum account will let you submit bugs.
More info on the bugtracker in this thread:
www.deviationtx.com/forum/3-feedback-que...racker-testing#29157

Once I have everything tested, I'll make the above changes, but it may take some time.