| *** mgedmin has joined #schooltool | 11:13 | |
| *** yvl has joined #schooltool | 12:47 | |
| *** mgedmin has quit IRC | 14:20 | |
| *** jstraw has joined #schooltool | 14:25 | |
| *** th1a has joined #schooltool | 14:43 | |
| *** jelkner has joined #schooltool | 14:48 | |
| *** ignas has joined #schooltool | 15:13 | |
| *** jstraw has quit IRC | 15:34 | |
| th1a | I just sent the 2009 plan I sent to Mark to the dev list(s). | 15:49 |
|---|---|---|
| *** fsufitch has joined #schooltool | 15:51 | |
| fsufitch | jelkner: ping | 15:51 |
| fsufitch | th1a: ping | 15:51 |
| th1a | fsufitch: Pong. | 15:53 |
| th1a | What's up? | 15:53 |
| * ignas read the plan | 15:59 | |
| fsufitch | th1a: oh hi | 16:12 |
| fsufitch | you responded | 16:12 |
| fsufitch | so, just making sure that it's EduCon 2.1 we're attending | 16:12 |
| fsufitch | to make sure i got the right websitre that im looking at | 16:12 |
| th1a | fsufitch: That's it. | 16:15 |
| fsufitch | th1a: cool | 16:17 |
| fsufitch | um.. then why are we not on the program? ;) | 16:17 |
| th1a | Well, you're not giving a full talk. | 16:17 |
| th1a | Also, we'll get you on there. | 16:17 |
| th1a | You got the mails about the plan though, right? | 16:17 |
| th1a | This is a relatively informal conference. | 16:18 |
| fsufitch | yeah i got them | 16:20 |
| fsufitch | and i got it :-P informal | 16:20 |
| jelkner | good morning all | 16:20 |
| th1a | Good morning jelkner. | 16:21 |
| aelkner | morning th1a | 16:27 |
| th1a | Good morning aelkner. | 16:28 |
| ignas | Hi everyone | 16:29 |
| jelkner | th1a: excellent plan! | 16:30 |
| th1a | Thank you jelkner. | 16:30 |
| jelkner | i would add one thing, though | 16:31 |
| th1a | ignas, yvl: Good evening. | 16:31 |
| th1a | uh oh. | 16:31 |
| jelkner | there is no mention of our growing group of outside developers | 16:31 |
| ignas | yvl's not here | 16:31 |
| jelkner | fsutichi, ccary, replaceafill | 16:31 |
| th1a | jelkner: Well, this is the plan specifically aimed at Mark. | 16:32 |
| jelkner | ahh | 16:32 |
| *** jstraw has joined #schooltool | 16:32 | |
| th1a | It is essentially the budget proposal. | 16:32 |
| jstraw | 'morning | 16:32 |
| th1a | So it really only covers things we're paying for. | 16:32 |
| th1a | Hi jstraw. | 16:32 |
| jelkner | but wouldn't he want to know that the ecosystem is growing? | 16:32 |
| *** dwelsh has joined #schooltool | 16:32 | |
| th1a | I've told Mark about replacafil in the past. | 16:33 |
| th1a | If that's what you're referring to. | 16:33 |
| th1a | Or do you mean something else? | 16:33 |
| jelkner | i just mean that there are now folks hacking on SchoolTool who he did not hire to do so | 16:33 |
| jelkner | that's a good thing | 16:33 |
| jelkner | mark of a project becoming a successful free software project | 16:34 |
| th1a | Yes. | 16:34 |
| th1a | Although we're still a long way from successful in that area. | 16:34 |
| th1a | I'm not sure I want to draw too much attention to that yet. | 16:34 |
| th1a | Anyhow... | 16:35 |
| th1a | I'm not planning on doing much work this week -- as independent contractors you guys can pretty much decide what you want to do. | 16:36 |
| th1a | What are you thinking aelkner & ignas? | 16:36 |
| ignas | th1a: well, I am doing some clean up, seeing that everything that has/had to be merged is merged | 16:36 |
| ignas | packages are proper | 16:36 |
| ignas | maybe I will do another release even | 16:37 |
| ignas | (i have added passwords to import) | 16:37 |
| th1a | I was thinking that a pre-holiday release might be a bad idea. | 16:37 |
| ignas | and it seems that we are starting to plan the new demographics for this release | 16:37 |
| th1a | Immediately post-holiday is probably better. | 16:37 |
| ignas | th1a: yeah, makes sense | 16:37 |
| th1a | So we don't get bug reports for Christmas ;-) | 16:38 |
| ignas | as in - what is involved and what we want to do | 16:38 |
| th1a | Yes. | 16:38 |
| th1a | We can spend most of the meeting talking about that, I think. | 16:38 |
| jstraw | what... bug reports are not good christmas presents? | 16:38 |
| th1a | aelkner: What's your status? | 16:38 |
| aelkner | i was going to work on cando bugs a little | 16:38 |
| ignas | jstraw: unless wrapped in functional tests - NO | 16:39 |
| aelkner | and coordinate with sla for the cas deployment | 16:39 |
| aelkner | that's it | 16:39 |
| aelkner | unless you have a request | 16:40 |
| th1a | Do we have all the outstanding SLA requests covered now? | 16:40 |
| th1a | Is there anything left on the list? | 16:40 |
| aelkner | well, there's the wizard-like form they requested for entering narratives within a section | 16:41 |
| th1a | It is really just a new link. | 16:41 |
| * th1a is looking at Launchpad... | 16:41 | |
| aelkner | you mean, we could just change the edit view to have next and previous buttons? | 16:42 |
| th1a | lp is slow today... | 16:42 |
| th1a | Yes. | 16:43 |
| th1a | Exactly. | 16:43 |
| aelkner | that's a good idea | 16:43 |
| th1a | Calling it a "wizard" makes it sound like way more than it is. | 16:43 |
| aelkner | i could look into that, too | 16:43 |
| th1a | Actually, it is something we need to do in a lot of places. | 16:43 |
| aelkner | i'm just used to wizzrd as a term for a form that asks multiple questions | 16:44 |
| th1a | Like, after you enter a new student, go directly to another new student form, etc. | 16:44 |
| th1a | Yes. | 16:44 |
| aelkner | so you have the intention of having next and previous in more than one place | 16:44 |
| aelkner | that's sonds like a good idae | 16:45 |
| th1a | It is a pattern. | 16:45 |
| th1a | In a lot of cases in SchoolTool you'll need to do the same thing over and over. | 16:45 |
| aelkner | but for now, sla would be happy with that feature for the narratives | 16:45 |
| th1a | Right. | 16:45 |
| th1a | Next question: should we have a meeting on the 29th? | 16:46 |
| jstraw | I don't really mind, I have to work anyways | 16:47 |
| jelkner | i won't be there | 16:47 |
| jelkner | (i'll be settling on the condo) | 16:47 |
| aelkner | sorry about that, my ISP is flakey | 16:47 |
| th1a | As the child of teachers, I don't celebrate New Years, which just signifies the bitter end of Christmas vacation. | 16:47 |
| th1a | But basically, if aelkner and ignas aren't planning on working much next week, we don't need a meeting. | 16:48 |
| aelkner | there won't be much to report, it's true | 16:48 |
| ignas | true | 16:48 |
| aelkner | lots of holiday parties and all | 16:48 |
| th1a | I just don't want you to not know what to do the rest of the week. | 16:49 |
| th1a | Either way, it isn't a stress for me. | 16:49 |
| aelkner | th1a: could you asign some bugs to me, and i could choose something if the time allows? | 16:49 |
| dwelsh | aelkner: how about the one critical bug??? | 16:50 |
| th1a | OK. | 16:50 |
| dwelsh | aelkner: the CanDo one??? | 16:50 |
| aelkner | dwelsh: i'm in the middle of fixing that one | 16:50 |
| dwelsh | awesome | 16:50 |
| aelkner | and i could do some others as well | 16:50 |
| th1a | So, no meeting on the 29th? | 16:50 |
| dwelsh | I'm going to work on CanDo website today and tomorrow. | 16:50 |
| th1a | dwelsh: Cool. | 16:50 |
| dwelsh | Bringing everything up to date. | 16:50 |
| aelkner | th1a: so besides some cando bugs, maybe just one schooltool bug assigned to me would keep me busy for the next two weeks | 16:51 |
| jelkner | th1a: before you drop the bag, i'd like to talk briefly about philly | 16:51 |
| th1a | Go ahead jelkner. | 16:51 |
| jelkner | i saw chris's email | 16:51 |
| th1a | Actually we're going to talk about demographics for a while, too. | 16:51 |
| jelkner | ok | 16:52 |
| jelkner | i can wait | 16:52 |
| th1a | OK. | 16:52 |
| th1a | So... demographics. | 16:52 |
| th1a | How are you feeling about it ignas? | 16:52 |
| ignas | well | 16:52 |
| ignas | if we do input fields with customizable labels | 16:52 |
| ignas | that are in the same add person form | 16:53 |
| ignas | i don't see why not support not just text fields, and maybe even ordering | 16:53 |
| ignas | also - the idea of having parent -> student relationship | 16:53 |
| ignas | and parents as separate objects | 16:53 |
| ignas | is something i think is more work that having customizable demographics form | 16:54 |
| th1a | ignas: Yes, I think you're right about the parent complexity. | 16:54 |
| ignas | *than having | 16:54 |
| th1a | otoh, things get ugly quick if you don't do that. | 16:55 |
| ignas | really? | 16:55 |
| th1a | Well, you get into the whole sibling issue. | 16:55 |
| ignas | yes | 16:55 |
| th1a | And you also have an undefined number of contacts per kid. | 16:55 |
| ignas | yes | 16:56 |
| ignas | I am not sure sibling issue is best solved through third object | 16:56 |
| th1a | If we only allowed two it would be pushing it. | 16:56 |
| th1a | Really? | 16:56 |
| ignas | i mean - i'd find it easier to have a link between two students for example | 16:56 |
| ignas | instead of having a Parent/Contact container | 16:56 |
| ignas | because that avoids the data collection/management issues | 16:57 |
| ignas | so when you create this relationship - contact persons are merged | 16:57 |
| ignas | contact person lists | 16:57 |
| ignas | if you break it - copied to be the same for both students | 16:57 |
| jstraw | what critical bug is this? | 16:58 |
| ignas | that means if you do it by mistake - you can recover by removing extra contacts from both students | 16:58 |
| ignas | and if you remove a student - nothing is lost | 16:58 |
| th1a | This is not a bug -- it is the future demographics/contact system. | 16:58 |
| ignas | or - contacts are lost | 16:58 |
| jstraw | nm... I'll bug dwelsh later (I just messed up my client for a sec) | 16:58 |
| ignas | if it's the only student | 16:58 |
| ignas | i mean Manage -> Persons, Groups, Parents | 16:58 |
| ignas | seems a bit nasty | 16:59 |
| ignas | maybe you could define usecases | 16:59 |
| ignas | without sticking to some implementation? | 16:59 |
| th1a | Yes, but I think the edge cases get even nastier if you don't have parent objects. | 16:59 |
| jelkner | be sure to keep in mind the parent logs in to see how there children are doing story | 16:59 |
| ignas | like what tasks and in what ways is it going to be done | 17:00 |
| jelkner | schooltool is a web app, that story is powerful | 17:00 |
| th1a | Like, what if you have two half-siblings that have the same step-parents but different parents. | 17:00 |
| ignas | jelkner: i am keeping it in mind | 17:00 |
| ignas | th1a: hmm, now that one is nasty | 17:00 |
| ignas | so I guess we are picking the "support everything possible, even though it'll be complicated" way of things | 17:01 |
| th1a | Also, these contacts might be non-parents, like, say probation officer, so they'll tend to not be shared among siblings. | 17:01 |
| th1a | Well.... | 17:01 |
| ignas | because suddenly if we have these "parent" things | 17:01 |
| ignas | that are not parents | 17:01 |
| ignas | we can't do "sibling inference" from them anymore too | 17:02 |
| ignas | i mean - if 2 students have the same contact - it does not mean anything | 17:02 |
| th1a | That's why I think sibling inference is a bad idea. | 17:02 |
| jelkner | i agree | 17:02 |
| ignas | so if we want to do siblings - we must do separate "contact" "parent" "sibling" stuff | 17:02 |
| ignas | also - some of the contacts apparently will be employees | 17:02 |
| ignas | as in - they will be Persons | 17:02 |
| th1a | I don't see any reason we need to know explicitly who is a sibling. | 17:02 |
| th1a | Someone else brought that up. | 17:03 |
| jelkner | yeah, forget siblings | 17:03 |
| jelkner | yagni | 17:03 |
| th1a | I might need to access all a kid's contacts. | 17:03 |
| th1a | Or, I might want to send an email to all the contacts on my list of adult contacts. | 17:03 |
| jelkner | we should get the word right | 17:03 |
| th1a | Eh, forget the second case there. | 17:04 |
| jelkner | we use parent/guardian | 17:04 |
| jelkner | but the idea is a responsible adult | 17:04 |
| jelkner | for that student | 17:04 |
| jstraw | there should be no separate parent from person either | 17:04 |
| jelkner | legally responsible | 17:04 |
| jstraw | imo | 17:04 |
| jelkner | contact doesn't really capture that | 17:04 |
| jelkner | it seems more informal than what we want | 17:05 |
| th1a | Well... schools may use it different ways. | 17:05 |
| jelkner | but as long as we are dealing with minors | 17:05 |
| jelkner | the role of legal responsiblity will always be important to a sis | 17:06 |
| aelkner | responsible adult sounds like a good name for the contact | 17:06 |
| jelkner | all minors have such legal guardians | 17:06 |
| aelkner | allowing that person to login as well | 17:06 |
| th1a | I don't think this case is limited to responsible adults. | 17:06 |
| jelkner | or they can't be in school | 17:06 |
| aelkner | to check the student's record | 17:07 |
| th1a | I think contact is the right term -- but a contact doesn't necessarily get access. | 17:07 |
| jelkner | but capturing who those legal guardians are is important | 17:07 |
| th1a | This may be the person I call if Johnnie breaks his arm. | 17:07 |
| jelkner | they are the ones permitted by law to see the students records, for example | 17:07 |
| th1a | And mommie and daddy aren't accessible. | 17:07 |
| th1a | No, this is not necessarily those people. | 17:07 |
| jstraw | yea... there is the emergency contact list too | 17:07 |
| ignas | ok, so we need contact management, and a list of contact people that can be related to Students in various ways "Parent" "Legally responsive" "Officer" "Whatever", my question is - do these contact/responsible people ever map with school tool persons? | 17:07 |
| jstraw | ignas: is there any reason they can't be persons as well? | 17:08 |
| jelkner | that kind of thing is better done as fields on the Student | 17:08 |
| jelkner | we don't need a seperate person for that | 17:08 |
| jelkner | they never need to log in, for example | 17:08 |
| jstraw | jelkner: I disagree, there is a lot of information and a variable number of those contacts | 17:08 |
| th1a | They could be persons, or they could be simplified persons. | 17:08 |
| ignas | jstraw: well - now you have 10k of persons, you will suddenly have 30K of persons, and 20K of them will have totally different management/archival semantics | 17:08 |
| ignas | jstraw: also - teachers/admins will not want to see them most of the time they are dealing with persons | 17:09 |
| jstraw | jelkner: people don't all log in (in a lot of schools students don't login) | 17:09 |
| th1a | I'm thinking this is a separate set of persons than current schooltool persons. | 17:09 |
| jstraw | ignas: ok... | 17:09 |
| ignas | so either they are not persons, or we rework persons and start separating teachers/students/employees/contacts | 17:09 |
| th1a | If a teacher is also a parent they get two unrelated objects. | 17:09 |
| jstraw | ignas: I like that idea somewhat better | 17:10 |
| ignas | jstraw: yes? | 17:10 |
| jstraw | I think the better separation is students / adults | 17:10 |
| ignas | yeah, that might make some sense | 17:10 |
| jstraw | in reality students are the type of person with the actually different piece of data we want to record | 17:10 |
| th1a | Hm... | 17:11 |
| jstraw | employees/contacts are a smaller set of data | 17:11 |
| jstraw | that also helps the 'advisor' role that SLA has too | 17:11 |
| th1a | Yes, but contact-persons don't do much directly, ever. | 17:11 |
| th1a | Someday a contact-person might log in and look at calendars, but they'll probably never have their own calendar. | 17:12 |
| th1a | For example. | 17:12 |
| ignas | th1a: well - i think the plan was, at least in the long run to have some contact persons (the legally responsible ones) log in and see grades for example | 17:12 |
| ignas | yeah | 17:12 |
| ignas | that's true | 17:12 |
| ignas | they will never have their calendars | 17:12 |
| jstraw | th1a: yes, but that is part of their profile | 17:12 |
| ignas | they only get readonly access on the student they are related to data | 17:12 |
| jstraw | and should be configurable | 17:12 |
| th1a | I'm just saying that students and teachers are more alike each other than teachers are like contact-persons. | 17:13 |
| jstraw | th1a: I don't really see that... | 17:13 |
| jstraw | th1a: students have full demographic data, teachers and contacts have more minimal contact information | 17:14 |
| jstraw | so from a data stand point I see students different | 17:14 |
| jstraw | from an access standpoint, I think that using groups would be the best way to configure all of that | 17:14 |
| th1a | For SchoolTool 1.0, contact-persons are just for organizing relationships and contact info. | 17:15 |
| th1a | They don't log in at all. | 17:15 |
| th1a | Maybe in the future they do. | 17:15 |
| jstraw | it also lets you take a person back and forth between different levels of access | 17:15 |
| jstraw | without recreating data | 17:15 |
| th1a | The contact/teacher use case is not important. If I have to do double address entry when a teacher who is also a parent moves, that's not a big deal. | 17:16 |
| jelkner | th1a: then why not just add them as data to the Student? | 17:16 |
| jelkner | we should do the simplest thing that works | 17:16 |
| jelkner | we get into trouble when we do this big design up front | 17:17 |
| jelkner | let the stories drive the solution | 17:17 |
| ignas | jelkner: because suddenly you have problems with "1 contact has 2 students" | 17:17 |
| th1a | It becomes a many to many relationship very quickly. | 17:17 |
| ignas | jelkner: and yes - in this case i am all for simple | 17:17 |
| ignas | th1a: sorry, but I knew like 2 guys in my class that had their siblings in the same school | 17:18 |
| th1a | Using hacks to implement a many to many solution with a one to one design is not easier. | 17:18 |
| ignas | th1a: i mean - it is a valid usecase, but you are suggesting something that takes a month over something that takes a week... | 17:18 |
| ignas | th1a: i'd go with - if one contact for 2 students - update it twice | 17:19 |
| th1a | The other thing is that it makes the student demographic forms much longer. | 17:19 |
| ignas | th1a: ? | 17:19 |
| ignas | th1a: tabs, separate objects | 17:19 |
| ignas | a list of small contacts objects | 17:19 |
| ignas | that you can add any ammount to a student | 17:19 |
| ignas | that are stored on a student | 17:19 |
| ignas | what I am opposing is a global contacts container | 17:19 |
| th1a | Hrm. I think I'm proposing small contacts objects. | 17:20 |
| th1a | It is just where they are put? | 17:20 |
| ignas | yes, because in one case - there are no relationships | 17:21 |
| ignas | thus there are no "dangling" contacts | 17:21 |
| ignas | in the contacts container | 17:21 |
| ignas | there are no problems with "delete contacts when deleting person" | 17:21 |
| ignas | contact is a property of a person and has the same lifetime and permissions as the person | 17:22 |
| th1a | So you're not dealing with the sibling issue then. | 17:22 |
| th1a | The thing is, people who weren't just mistakes should never be deleted anyhow. | 17:23 |
| ignas | nope, no siblings | 17:23 |
| ignas | th1a: yes, but mistakes will happen | 17:23 |
| ignas | especially while the system is young | 17:23 |
| jstraw | ignas: as an extension to that | 17:23 |
| jstraw | how about just adding people to the system (same as any other) | 17:24 |
| jstraw | and just linking to them | 17:24 |
| ignas | th1a: i mean - the suggestion was saving some time, by not updating identical contacts twice | 17:24 |
| th1a | What if you assumed that you don't delete contacts when you delete the student? | 17:24 |
| ignas | th1a: i am not convinced this usecase mandates the additional month of work | 17:24 |
| jstraw | so instead of making small objects attached to a student | 17:24 |
| jstraw | make a list of links | 17:24 |
| jstraw | and worry about what type of user they are later | 17:24 |
| jstraw | it saves the multiple stores work, and provides the many to many support | 17:25 |
| ignas | jstraw: what about data retention laws? suddenly you have 3x the amount of people, and suddenly you don't want to see most of them in person lists | 17:25 |
| jstraw | ignas: use groups to filter | 17:25 |
| ignas | jstraw: Group, Section , member/leader/teacher selection widgets | 17:25 |
| jstraw | we don't use the teacher/student groups nearly enough in SchoolTool | 17:26 |
| ignas | jstraw: you know how fast it is with CanDo at the moment | 17:26 |
| jstraw | ignas: so we fix it | 17:26 |
| th1a | I'm just having trouble understanding why one is so much more complicated than the other. | 17:26 |
| ignas | jstraw: +week to the estimate | 17:26 |
| jstraw | ignas: ok... that work still needs to be done to groups anyways | 17:27 |
| *** fsufitch has quit IRC | 17:27 | |
| th1a | I mean, if it really takes a month to do this with the ZODB, we probably should have killed this entire project three years ago. | 17:28 |
| ignas | it's not data structures | 17:28 |
| ignas | and not ZODB | 17:28 |
| ignas | it's ui, you want to "manage" contacts, so you want to list contacts without persons attached, you want to have a way of querying all persons for a contact | 17:28 |
| ignas | so you have separate views for contact objects, for contact objects on person | 17:29 |
| th1a | Ah. Well, just because we can do those things doesn't mean we have to. | 17:29 |
| * ignas can't understand why on one hand you want it "good" and on the other hand "bad" at the same time | 17:30 | |
| ignas | i mean - we discuss edge usecases like siblings of divorced parents | 17:30 |
| ignas | and use "yagni" argument 5 lines after that | 17:30 |
| th1a | Well, we're having a discussion. | 17:31 |
| ignas | if we want it the most simple way - contact objects on a person, no thinking about relationships, no thinking about collecting unused contacts, no contact list management/filtering/searching | 17:31 |
| ignas | if we want it done well | 17:31 |
| ignas | so we add a Contacts container | 17:31 |
| ignas | we have filtering to find dangling contacts | 17:31 |
| ignas | we have proper filtering and searching for contacts | 17:31 |
| ignas | also we have views for contacts, to see which persons are attached to them properly | 17:32 |
| jstraw | ignas: yagni doesn't mean don't discuss, (in fact it means for sure do) it means don't implement until you need it | 17:32 |
| th1a | What I'm trying to say at this point is that multiple siblings in a school is not an edge case. | 17:33 |
| jstraw | and, it is easy to be a little overzealous in using it | 17:33 |
| jelkner | i'm concerned that if we commit to a big investment in new infrastructure before we have real users and real use cases, we are going down the wrong road | 17:33 |
| jstraw | jelkner: are you going to need that infrastructure in 2 years | 17:34 |
| jstraw | or better yet are we going to ask to build it out by then | 17:34 |
| jelkner | then write it in two year | 17:34 |
| * jstraw thinks this is more a brainstorming session | 17:34 | |
| th1a | I'm just trying to figure out why one is a big investment compared to the other. | 17:34 |
| th1a | Yes -- brainstorming! | 17:34 |
| jstraw | jelkner: not a good idea, it will add 1 month to the time it takes | 17:34 |
| th1a | Don't panic. | 17:34 |
| jstraw | jstraw: XP has a hole, it throws yagni over good design | 17:34 |
| ignas | because of locality, one is simple dangling object on a person, that also is dumb | 17:34 |
| ignas | other is "global container" "objects" "relationships" | 17:35 |
| jstraw | jelkner even :) | 17:35 |
| jelkner | jstraw: all of the successes we have had in the past year have come from writing real code for real people, and *not* listening to what you just said | 17:35 |
| th1a | We don't need a general XP discussion. | 17:35 |
| jelkner | i'm not sure about that | 17:36 |
| th1a | I am. | 17:36 |
| * jstraw takes it to pm | 17:36 | |
| th1a | I think we're in agreement, ignas and I at least, that we just need to be able to associate several simple contact items with a student. | 17:37 |
| jstraw | th1a: that works for me | 17:37 |
| jstraw | ignas: would a copy function be a possibility | 17:38 |
| th1a | We have no pretense of deciding this today, but I'd like to at least confirm where we are. | 17:39 |
| * ignas is trying to estimate | 17:39 | |
| ignas | th1a: yes, also - if need will arise, migrating from contacts on person to global contacts directory | 17:40 |
| ignas | is not too difficult | 17:40 |
| ignas | merging identical contacts is even possible | 17:40 |
| th1a | Well, if we have an upgrade path, that's not too bad. | 17:41 |
| th1a | This is probably a good place to stop. | 17:42 |
| ignas | i mean - just take contacts objects from persons, put them all into a gloabal container, and transform __parent__ relationship into a schooltool relationship | 17:42 |
| th1a | So... no meeting next Monday, then? | 17:43 |
| ignas | nah | 17:43 |
| ignas | so targets for the release are Rework current demographics fields, 4-5-many user defined demographics fields, contacts for persons, group and other relationships optimization | 17:44 |
| ignas | export/import polishing | 17:44 |
| ignas | anything else to think about on Christmas Eve | 17:44 |
| ignas | ahh, Eve, th1a - you're red! | 17:44 |
| th1a | Ah, you joined the other alliance. | 17:45 |
| ignas | KW | 17:45 |
| th1a | What's that stand for? | 17:45 |
| ignas | Kraftwerk | 17:46 |
| th1a | Oh... organizing reports SchoolTool-wide. Also making students inactive. | 17:46 |
| th1a | Oh yeah, Kraftwerk is definitely red. | 17:46 |
| aelkner | that's german for power plant | 17:46 |
| aelkner | or nover mind | 17:47 |
| th1a | What happened to the other alliance you guys were going to join? | 17:47 |
| ignas | well, they left us hanging for like a month | 17:47 |
| ignas | so we got fed up | 17:47 |
| th1a | Have a great holiday guys and get ready for a busy 2009! | 17:48 |
| * th1a drops the bag of gravel. | 17:48 | |
| th1a | Does KW hold any space? | 17:48 |
| ignas | yep | 17:49 |
| ignas | a constelation at least | 17:49 |
| ignas | and some systems around it | 17:49 |
| th1a | Ah. Scalding Pass. | 17:50 |
| th1a | We're going in the other direction. | 17:50 |
| th1a | Paradox Collective? | 17:50 |
| th1a | That's you? | 17:50 |
| ignas | yep | 17:51 |
| th1a | We're moving into Catch. | 17:52 |
| *** jelkner has quit IRC | 18:05 | |
| *** ignas has quit IRC | 19:15 | |
| *** jstraw has quit IRC | 19:56 | |
| *** th1a has quit IRC | 20:59 | |
| *** jelkner has joined #schooltool | 21:17 | |
| *** elarson_ has joined #schooltool | 21:25 | |
| *** jcrowley has joined #schooltool | 21:26 | |
| *** elarson_ has quit IRC | 21:29 | |
| *** replaceafill has joined #schooltool | 21:33 | |
| *** dwelsh has quit IRC | 22:03 | |
| *** jcrowley has quit IRC | 22:09 | |
| *** jelkner has quit IRC | 22:21 | |
| *** replaceafill has quit IRC | 22:21 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!