First, thank you to everyone who has spent a couple minutes providing feedback on qorbiter for android. After some serious thought and discussion as well as observation, I think its time to slow this train down a bit. I dont mean development will stop. Not in the least bit. But, I am guilty of jumping to the shiniest new object. Also, some other things need to be taken into consideration. Qorbiter now has binaries for:
*x86 Linux - Desktops
*Arm linux - Raspberry pi's
*Android
*OS X
Other platforms:
Windows is touch and go at this time...
Sailfish ive just not gotten around to
Same with blackberry
Made my first iOs app yesterday
This means there needs to be both active skin development and testing for all these platforms (no, not right now!) But in light of this, I think I as a developer have a duty to take this a little more seriously, as its graduated far from a prototype toy. So, with all of that long winded statement out of the way, im proposing that we start working using the concept of agile development. There are many ways to do this, but I will share with you my understanding of this process.
1. Backlog - This is basically the entire wishlist of features. Everything you can think of. It supposed to be weighted by difficulty. A challenge here is to decide on how we deal with features across platforms.
2. Backlog Grooming - Taking stuff from the wish lists and putting it on the sprint task list. You are careful not to overload the sprint with too many tasks. the goal is to get things working within the sprint.
3. Sprint - Development time where things are developed. It could be bug fixes, new features, or a mix of both.
4. Sprint demo - Demonstration of sprint implementation
People involved.
Product Owners - This would normally be the client. They fill the backlog, weight the importance of features (1-5), and test features after a sprint. In this case, its the linuxmce community.
Scrum Master - This person directs the flow of traffic. Part project manager / Part developer the help with sprint planning and normally moderate daily standups (something we cant do)
Developer - Implements features and fixes bug according to the sprint plan.
SO, with all that said, basically I want to do something similar to this where...
*QOrbiter feature list / backlog is put in wiki.
*Tasks get groomed from feature list in wiki, to active tickets in trac.
*Tasks get completed over a 2 week sprint, people test
*Rinse repeat
The tasks could be picked by the community every two weeks for most important focus.
Pros:
More stable releases
Targeted feature completion.
Easier update paths
Cons:
Slower updates
Community decisions can be slow
Requires involvement of everyone (cause you know, its your product)
So, let me know what you think, but I seriously leaning this direction with the first tasks being
*Improve initial installation experience.
*Fix skin detection to properly detect phones / tablets
*Add remote screens
*Fix remote errors in sizing, commands sent.
-golgoj4
