Part two of the TODO Manager article series is up - Database and Domain Design is available here, in which I don my gear and go exploring in the barren wastes of confusion and spite with only a one-page wiki spec as a map, seeking the one true design for my domain that will allow me to build an app atop it that meets the requirements in full.
Comments, as usual, live here.
Due to various real live issues (nothing tragic, just boring stuff like buying food...) I've only yet had time to review your Database and Domain Design.
The short story: Wow! You're putting a lot of effort into this.
And the details: At first, I had slight problems understanding the Class definitions, but apparently I'm not a complete moron, so I worked out their meaning. Still, I'm left with one question: Is this some Reaction/Moose syntax, or pseudocode?
User Management. Your design forces people to register yet another account. Which is a tiny bit annoying, but I think that it will make the quality of the site and it's data better. And as we're dealing with real money, forcing people to use a valid email adress to get an account makes sense. Maybe it would be nice to let people submit TODO tests without registering first. But then we (Vienna.pm) would have to decide on our own if a task was finished successfully - and we'd love to delegate this work
So I think adding a proper User Management System is unavoidable.
Versioning. This seems to make sense, though I have to admit that I couldn't completely parse the "SELECT this.revision_id, this.changed_by_id, this.changed_at FROM
TodoStates. Class::Workflow looks interesting, and I look forward for an example usage of it. Is it possible to also attach comments to changes in this state? Maybe something like changed_comment in todo_version?
Approval and Review. As you said, a TODO Implementation has to be approved by the submitter and Vienna.pm. I guess that the check if an Implemenation has two Approvals is not part of the Database/Domain Design?
Maybe Vienna.pm should also have a 'veto' during Review: After the submitter has finished his/her review (which is presumably technical), Vienna.pm has to review the social/financial part (eg to avoid scams where person A submitts a fake TODO and person B implements it). Or am I too paranoid?
Summary: A very interesting read, and I say go ahead with the implementation (if you haven't done so already...)
Re:wow
mst on 2008-01-03T15:16:14
Well, we need to be able to support people who don't have a login anywhere else they want to use so that's the part of the functionality that -has- to be implemented - plus we have to have the e-mail address pretty much no matter what for notification purposes. However I think we should probably auto-login PAUSE accounts if they provide an @cpan.org address and an appropriate password - I can handle that the same way rt.cpan does by doing a quick POST to PAUSE and checking the results (I can never decide whether I think that's hacky or elegant
:). As for the states, the example of Class::Workflow will come when I write the code for it, and I the events that change states mostly have notes fields anyway. If you're making a transition that doesn't I'm hoping to make the UI such that you can make a comment on the same form, so while the two aren't linked in the DB they'll get the same timestamp and will appear in the event log for the todo next to each other.
The "have we got enough approvals" part -is- going to be app-side, because I can see us wanting to tweak the approval approach quite a bit (notice you've already made one suggestion for a tweak
;) so I want to be able to achieve that with a quick code deployment. Plus it means when that gets changed the old data is still accurate. Perhaps we should simply enforce from the app that the submitter approves first and the vienna person second? I'm currently getting out from under a pile of backed-up-from-the-holiday work but will be implementing starting tomorrow.
