| *** didymo has joined #schooltool | 00:01 | |
| *** povbot has quit IRC | 00:06 | |
| *** srichter has joined #schooltool | 00:23 | |
| *** jinty has left #schooltool | 01:05 | |
| *** didymo has quit IRC | 01:18 | |
| *** didymo has joined #schooltool | 03:07 | |
| *** didymo has quit IRC | 04:46 | |
| *** didymo has joined #schooltool | 06:11 | |
| *** th1a has quit IRC | 08:30 | |
| *** Aiste has quit IRC | 10:12 | |
| *** didymo has quit IRC | 10:15 | |
| *** Aiste has joined #schooltool | 11:25 | |
| *** jinty has joined #schooltool | 11:51 | |
| povbot` | /svn/commits: * jinty committed revision 5385: | 12:05 |
|---|---|---|
| povbot` | /svn/commits: A little bit of documentation of the automatic build config. Also attempt to make sure that mkschooltoolinst asks no questions (bad for automation...) | 12:05 |
| jinty | yay, nightly tarballs work again! | 12:23 |
| *** mgedmin has joined #schooltool | 12:50 | |
| *** ignas has joined #schooltool | 14:15 | |
| *** jinty has quit IRC | 16:06 | |
| *** jinty has joined #schooltool | 16:48 | |
| *** mgedmin has quit IRC | 16:51 | |
| *** jinty has quit IRC | 16:54 | |
| *** mgedmin has joined #schooltool | 17:58 | |
| *** th1a has joined #schooltool | 18:56 | |
| *** erchache has joined #schooltool | 19:06 | |
| erchache | hi | 19:06 |
| *** jinty has joined #schooltool | 19:12 | |
| th1a | srichter: ayt? | 19:20 |
| th1a | hoi ignas. | 19:27 |
| ignas | hi | 19:27 |
| ignas | a question - we need an Abscence explaination workflow, or attendance tracking workflow ? | 19:28 |
| th1a | My question exactly. | 19:28 |
| th1a | You're definitely right about mixing tardy into the workflow. | 19:28 |
| th1a | Why would we need IsPresent? | 19:29 |
| ignas | well - if it was a workflow for "attendance tracking" | 19:30 |
| th1a | We're not tracking the state of the student. | 19:30 |
| ignas | then it would be a resolution state | 19:30 |
| ignas | but if we need a workflow for "resolution of unexplained tardies/abscences" | 19:30 |
| ignas | or two workflows for them | 19:30 |
| th1a | It is probably one workflow. | 19:31 |
| ignas | for resolving an abscence ? | 19:31 |
| th1a | Absences and tardies. | 19:31 |
| th1a | I mean, it would have two branches. | 19:31 |
| ignas | well it all begins with abscence | 19:31 |
| ignas | then splits into unexplained abscence or a tardy | 19:31 |
| th1a | Since absences become tardies. | 19:31 |
| th1a | Right. | 19:31 |
| ignas | so physically it is an abscence resolution | 19:32 |
| th1a | One process. | 19:32 |
| ignas | abscecne can resolve into an explained tardy eventually | 19:32 |
| ignas | if i understand you correctly | 19:32 |
| *** vidasp has joined #schooltool | 19:33 | |
| th1a | Yes. | 19:33 |
| th1a | Fundamentally, I think of this as a document workflow. | 19:33 |
| ignas | so if i am marking someone as absent | 19:33 |
| ignas | and then say oops, i misspelled the name | 19:33 |
| ignas | i will have to "DELETE" the workflow ? | 19:34 |
| ignas | and the permission "who can delete a workflow thus making the abscence into presence" | 19:34 |
| th1a | Well, once we have more varieties of explanations, that would be one end state. | 19:34 |
| ignas | will be hardcoded into our application | 19:34 |
| th1a | You wouldn't delete the workflow, you'd resolve it as an error. | 19:35 |
| ignas | oh | 19:35 |
| ignas | i see | 19:35 |
| th1a | Well, there'll just be codes. | 19:35 |
| th1a | Not different states. | 19:35 |
| th1a | Believe me, there are codes. | 19:35 |
| ignas | well - we will have 2 states anyway ... 1 state - there is a workflow, another state - there is no workflow ... | 19:35 |
| th1a | You'll be parsing lists of them soon enough :-( | 19:35 |
| th1a | That's for a later date, however. | 19:36 |
| th1a | One other thing that came up when doing the workflow is that we'll probably have to define an AttendanceAdmin group which will include the members of the various groups who have permission to administer attendance. | 19:38 |
| th1a | WfMC seems to want to assign the workflow to one group/role. | 19:38 |
| th1a | So anyhow, I think the workflow starts when a student is marked absent. You don't need a workflow if they are present. You aren't processing the student, you're processing the absence report. | 19:46 |
| *** jinty has quit IRC | 19:46 | |
| th1a | The student is not changing state. | 19:46 |
| th1a | (OK, WfMC doesn't use states, but you know what I mean) | 19:47 |
| *** erchache has quit IRC | 19:52 | |
| povbot` | /svn/commits: * hoffman committed revision 5386: | 20:01 |
| povbot` | /svn/commits: Adding a couple points to the WfMC tutorial. | 20:01 |
| povbot` | /svn/commits: * vidas committed revision 5387: | 20:06 |
| povbot` | /svn/commits: Suggested another attendance API. | 20:06 |
| ignas | one question is - IIRC if workflow reaches the end state - it can't be modified anymore | 20:28 |
| ignas | what then ? | 20:28 |
| ignas | how would you unexplain an excused abscence ? | 20:28 |
| th1a | Hmm... | 20:28 |
| th1a | Well, it doesn't seem like it would require a workflow, as such, in most cases. | 20:29 |
| th1a | That is, you're going to end up with a code annotated to the absence, or something like that. | 20:29 |
| th1a | You can always have a subsequent method of modifying it and logging the change. | 20:30 |
| th1a | I would imagine. | 20:30 |
| th1a | But that would just be a sort of admin override. | 20:30 |
| th1a | It wouldn't routinely trigger a whole new series of steps. | 20:31 |
| th1a | Make sense? | 20:31 |
| th1a | Or perhaps, in the future, when this whole workflow is more complex, we'll see why we need to include admin overrides in the workflow, but this workflow is just to get started. | 20:35 |
| th1a | This version. | 20:36 |
| ignas | i guess we can rewire everything in that case ... | 20:42 |
| ignas | because i thought that some schools might have strict rules/workflows for unexplaining/modification of such data | 20:42 |
| ignas | but we are not aiming at all the schools at the moment anyway | 20:42 |
| th1a | Well, the strict rule would probably be that a school administrator would have to do it. | 20:43 |
| th1a | But generally that would be the kind of thing that would mostly be sorted out face to face. | 20:43 |
| th1a | I mean, you could have a system that allowed parents to submit appeals online, etc., etc., etc. | 20:43 |
| th1a | But that's a whole system in itself. | 20:44 |
| th1a | The main thing is that the change would have to be logged. | 20:44 |
| ignas | i see | 20:46 |
| th1a | Note that my approach here is to put something simple together that we can plop in front of schools for feedback. | 20:48 |
| th1a | I think we'll save everyone time and confusion by showing them something simple before asking for detailed requrements. | 20:48 |
| th1a | Rather than simply asking them to imagine their requirements in a void. | 20:49 |
| ignas | well - using wfmc is still looking contradictory to keeping it simple ... | 20:49 |
| ignas | what is the point of using extensible foundation | 20:49 |
| ignas | and not building extensibility | 20:49 |
| ignas | and extensibility is not the "simplest thing that works" | 20:50 |
| th1a | Not sure what you mean by not building extensibility. | 20:50 |
| ignas | sorry, i just caugfht myself wanting overengineer everything again :/ | 20:50 |
| ignas | the difficult part to mee seems integrating the workflow not the size of the workflow itself ... | 20:51 |
| ignas | i might be very wrong though | 20:52 |
| th1a | You're right. | 20:52 |
| ignas | that's why i am thinking of - how deep will we integrate it | 20:52 |
| ignas | which we will not be able to change by modifying XML | 20:52 |
| ignas | or adding some code later (easily at least) | 20:53 |
| ignas | still - i don't know enough about wfmc, because well - i haven't implemented anything using it yet ... | 20:54 |
| th1a | Right. | 20:54 |
| ignas | so it might be a lot simpler than i think | 20:54 |
| th1a | That's why I'm trying to keep this first case simple. | 20:54 |
| th1a | You can spiral off into grand visions of the whole application being built around an interlocked series of workflows. | 20:55 |
| th1a | But I think that's too much. | 20:55 |
| th1a | I see this as something that will help keep the application sane 5 to 10 years down the road. | 20:56 |
| th1a | Yet hopefully not so complex that we'll miss all our deadlines ;-) | 20:56 |
| ignas | i seem to understand it | 21:04 |
| th1a | Once I actually stepped through srichter's doc last night I had more luck with JaWE than I have in the past. | 21:04 |
| th1a | That's a crappy UI overall. | 21:04 |
| ignas | true | 21:10 |
| ignas | managed to get stuck in like 5 seconds :) | 21:10 |
| *** vidasp has quit IRC | 21:44 | |
| povbot` | /svn/commits: * mg committed revision 5388: | 21:46 |
| povbot` | /svn/commits: Lists in ReStructuredText shouldn't be indented (if they are, you get a <ul> inside a <blockquote>). | 21:46 |
| povbot` | /svn/commits: Fixed a typo (follwed). | 21:46 |
| povbot` | /svn/commits: * mg committed revision 5389: | 22:09 |
| povbot` | /svn/commits: Converted the bulleted list of terms into a definition list. | 22:09 |
| povbot` | /svn/commits: Corrected the spelling of work items. | 22:09 |
| povbot` | /svn/commits: Changed "the the" to "to the" in the following sentence: | 22:09 |
| povbot` | /svn/commits: For manual applications you also need to add the application *the* the participant's work items. | 22:09 |
| povbot` | /svn/commits: I'm not sure I picked the correct pronoun, since I have a very hazy idea about the relationship between applications and work items. | 22:09 |
| *** Aiste has quit IRC | 22:30 | |
| *** Aiste has joined #schooltool | 22:53 | |
| *** mgedmin has quit IRC | 22:58 | |
| *** ignas has quit IRC | 23:18 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!