here’s a rough roadmap for what’s ahead - not sure how well the schedule will hold. and a lot of this is sort of notes to myself, since i don’t have a good project management database/tool yet.

this week into next

  • finish adding feature requests and bugs from email, blog and forum to the database (4 hrs)
  • go through entire feature list, assign cost and benefit and prioritize them (rank 1-5) and assign to future versions (10 hrs)
  • clean up the project database - make items more readable, merge duplicates, etc (8 hrs)
  • move project database from access to mysql or sqlite (10 hrs)
  • publish entire project database via ruby on rails (20 hrs?)
  • make it interactive, so people can submit feature requests, bugs, annoyances, questions, answers, comments, related projects, tools, documentation, websites, themselves (including beta tester status, mail notification preferences etc) and vote on features. not sure how involved this will be yet, though could get a really bare interface up pretty quickly. (20+ hrs?)
  • move the forum entries into the project database and close the forum (rather have it all tied into the project database) (6 hrs)

note how most of this is just project management stuff - i haven’t seen any (open source) tools that will do all the things i want to do, and i figure doing it myself will help drive development of some features that i want neomem to have.

next week

  • do a couple of high priority features and bug fixes for a ‘quick’ version 1.2 release (20-30+ hrs)

november and december

  • continue working out the new architecture on paper - i’ve learned that it’s best to hold off even on prototyping, because it’s so much fun to keep adding new features that it becomes the actual program, before you’re really ready to start coding - a really bad project risk!
  • continue working on the project management database and website
  • convert other notes on planned features to database entries (a long, ongoing process - lots of notes on paper, in my neomem file, and on index cards)
  • move code repository from cvs to subversion (will be better for refactoring things, eg renaming files etc)
  • host the code repository online, so others can start contributing (even bug fixes and small features would be a great help)
  • make a table of contents for the code - (i don’t want to just throw the code at people and expect them to figure out where things are, like so many cvs repositories seem to do)

ultimately i’d like to lower the barrier to contributing to the code as much as possible, eg make it more like wikipedia. there are so many projects that i would love to contribute a little feature to here and there but it’s such a hassle to become acquainted with the code and the editors etc that i’ve never done it. going towards ruby or python will help with that - much easier to read than c++, and also plugins will just be text files.

imagine if anyone could just drill down to the code from the feature list and make a change to the code, without even registering (though as on wikipedia, it’s nice to do so so to keep track of who did what). the server would do the test and build and let the person download it and play with it. then when one of the editors had the chance to review the code they could approve it for general use. that’s my dream for how the website would work, anyway. i think it would be more doable with ruby or python though, since no compilation step on the server would be necessary.

probably by the end of the year i’ll be ready to start developing the program. most likely it will be from scratch, in ruby, with wxwindows for the gui. it will be version 2.0. i’m not sure what will happen with the old code yet - it’s visual c++/mfc, and it’s a bit of a mess. not sure if it would be worthwhile to try and migrate it slowly towards ruby, or just start from scratch. if nothing else, the views would be translatable to view plugins in the new architecture, especially if there’s a c++ to ruby translator to help with the syntactical stuff. i think i’d like to start from scratch with the backend though - there will likely be larger changes to the data structures there.

but all existing data will be migrated smoothly to the new version, one way or another - if nothing else by exporting to xml and importing into the new version.

Tags: No Tags