Hitesh,
It’s clear that taking the initiative to get involved months ago has helped you
research and understand the requirements of what you’re proposing. Well done.
The overall structure is fine. As to your technical approach, I’d personally
prefer to not involve MySQL at all for change management. Using directory
queues on the server (one for holding changes pending review, another for those
approved for commit), would probably be sufficient: patch files — basically an
on-disk file database instead of relational. This would let a dev on the
server manually inspect and fix, for example, if there were a merge conflict.
Plus, it’s just simpler to maintain — don’t have to worry about mysql
permissions, wouldn't force devs to work through a web browser, don’t have to
worry about mysql updates, etc.
Your development schedule looks reasonable, but it’s much easier to track if
you break the schedule up in terms of weeks (instead of 10-day blocks). There
are four bonding period weeks and twelve coding weeks. Can you characterize
your schedule in those terms?
A little more detail is needed in a few places including how the back-end will
be structured (maybe a diagram) and interact with the front-end. You are
primarily proposing a custom web application but don’t really describe the
implementation (language? framework? plugin?) or interface much (prototype user
interface mock-up and/or diagrams would be helpful). You can utilize the
bonding period to sort out the user interface and content in more detail so
once the coding weeks begin, you are almost entirely writing code.
The first 30 days (4 weeks) you propose converting all txt, html, latex, and
manual page docs, but that’s really out-of-scope for the coding weeks. That
conversion work should either be during the bonding timeframe, left to others
so you only focus on existing docbook, or you could propose writing scripts to
help convert them. We definitely want them all converted and I’d love for you
to do that conversion, but the GSoC coding weeks must primarily consist of
writing code. I suggest limiting your schedule to no more than two weeks of
non-coding activities (and that includes time writing a midterm and final
report, having discussions, testing, etc).
You also don’t itemize which docs or how many or how big they are, relatively
speaking. It obviously should (eventually) be all of them, but I know you’ve
been looking at this all a lot already and can probably be specific. If you
can, that will help demonstrate the scope of this effort to others.
I suggest eliminating sorting. The priority should be focused on 1) publishing
our docbook docs online, 2) allowing those documents to be edited online or
directly in the repo, and 3) having any committed edits automatically
reflected/republished online. Anything else is secondary and could be done
after 1/2/3 are robust, especially with moderation occurring after online edits
from #2. I do appreciate that you pushed adding new docs to near the end of
your timeline, but it’s also another candidate for elimination. That’s time
better spent on making the round-trip publishing more robust and featured,
ready for production use.
I’m also VERY interested in seeing you discuss how this will (or will not)
interact with a content management system — mediawiki, wordpress, and/or
confluence. If you’ve done any research with any of those three, please
include them in your proposal discussion. I would have thought writing a
plugin for one of those would be more desirable than something entirely custom,
even if it meant not using some Docbook tags. So if you’ve determined custom
is better, I’d like to see you discuss that analysis in detail.
Overall
Cheers!
Sean
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
