| *** balor has quit IRC | 00:27 | |
| *** alga has quit IRC | 03:01 | |
| *** aelkner_ has joined #schooltool | 05:08 | |
| *** aelkner has quit IRC | 05:10 | |
| *** aelkner_ has quit IRC | 05:23 | |
| *** aelkner has joined #schooltool | 05:24 | |
| *** Aiste has quit IRC | 05:59 | |
| *** balor has joined #schooltool | 08:24 | |
| *** yvl has joined #schooltool | 10:14 | |
| *** yvl has quit IRC | 12:32 | |
| *** jstraw has joined #schooltool | 15:16 | |
| *** th1a has joined #schooltool | 15:31 | |
| *** alga has joined #SchoolTool | 15:42 | |
| *** ignas has joined #schooltool | 15:50 | |
| *** jelkner has joined #schooltool | 15:51 | |
| jelkner | no meeting this morning? | 16:09 |
|---|---|---|
| ignas | why do you think so? | 16:10 |
| th1a | jelkner: The meeting is at 9:30 every week. | 16:10 |
| th1a | As it has always been. | 16:10 |
| jelkner | and i am completely discombobulated (as I have always been) | 16:12 |
| jelkner | th1a: good morning, anyway | 16:13 |
| ignas | discombo-what? | 16:13 |
| jstraw | lol | 16:13 |
| jstraw | ignas: jeff doesn't know what time it is | 16:14 |
| jstraw | ever | 16:14 |
| th1a | good morning jelkner. | 16:14 |
| jelkner | ignas: or which end it up | 16:24 |
| jelkner | s/it/is | 16:24 |
| ignas | :) | 16:25 |
| th1a | hello ignas, aelkner, jstraw. | 16:31 |
| ignas | hi | 16:31 |
| aelkner | hello | 16:31 |
| th1a | OK, ignas, how are the plans for the sprint looking? | 16:32 |
| aelkner | th1a: up late much last night celebrating? | 16:32 |
| th1a | That was a weird Super Bowl run. | 16:33 |
| jelkner | th1a: jstraw has an important agenda item for today | 16:33 |
| jelkner | did he tell you? | 16:33 |
| jelkner | we need to discuss deployment of the 8 cando instances | 16:33 |
| th1a | OK. We'll get to it after ignas. | 16:33 |
| ignas | th1a: i have the backend for indexing mostly set up (it replaces old person indexes successfully, so it's good for something) | 16:34 |
| ignas | also some code for demograpchics backend | 16:34 |
| ignas | and some small notes about views i will need implemented | 16:34 |
| ignas | i will get all that on "paper" before the sprint | 16:34 |
| ignas | don't know if Justas has finished the booking though, he is at home as he's feeling a bit sick | 16:35 |
| th1a | OK. | 16:35 |
| ignas | also - i will have to update a bunch of stuff | 16:35 |
| ignas | srichter has released Zope3.4 | 16:35 |
| th1a | Indeed. | 16:35 |
| ignas | and changed the KGS url | 16:35 |
| ignas | so the old one is not working anymore | 16:35 |
| th1a | Oh, yeah. | 16:36 |
| ignas | thus most of the checkouts are broken at this very moment | 16:36 |
| th1a | I guess that is a pain. | 16:36 |
| ignas | we don't want to have that in the sprint, do we? ;) | 16:36 |
| aelkner | ignas: i was going to report | 16:37 |
| th1a | Um... no. In fact, perhaps you should send out an email telling people what they should have ready to go for the sprint. | 16:37 |
| aelkner | a problem deploying to SLA this weekend | 16:37 |
| aelkner | so i guess i can see why | 16:37 |
| th1a | Ah... that would do it. | 16:37 |
| ignas | http://download.zope.org/zope3.4/3.4.0/versions.cfg | 16:37 |
| ignas | is the new url | 16:37 |
| ignas | http://download.zope.org/zope3.4/versions.cfg the old one | 16:37 |
| th1a | So this is the worst possible time for CanDo as well? | 16:37 |
| ignas | so in buildout.cfg replace the old one with the new one | 16:37 |
| ignas | and it should work | 16:38 |
| aelkner | cool | 16:38 |
| th1a | So basically we're going to need to start Friday morning with a grand explanation of the roadmap for the sprint? | 16:39 |
| th1a | In lieu of making you write an essay, ignas? | 16:39 |
| ignas | yeah | 16:39 |
| ignas | i guess so | 16:40 |
| ignas | more with a list of tasks | 16:40 |
| ignas | than a grand explanation ;) | 16:40 |
| th1a | Well, what are the high level goals -- I don't think most people outside of Lithuania know. | 16:40 |
| jstraw | I have no agenda item today... every time I go to work on it I get knocked away from it by something external | 16:41 |
| jstraw | and I can't talk right now | 16:41 |
| th1a | jstraw: Keep us posted. | 16:42 |
| ignas | change default fields for persons, add new fields for persons, add customizable fields for persons, add contacts | 16:42 |
| ignas | make all of that work fast enough to be useful through indexing | 16:42 |
| ignas | that's the "grand plan" ;) | 16:43 |
| th1a | OK. | 16:43 |
| ignas | other tasks are orthogonal to the great plan, and can be thought of as separate "lesser plans" | 16:43 |
| th1a | This is based on the schema I sent out a while ago? | 16:43 |
| th1a | I mean, the actual new fields? | 16:43 |
| * ignas goes to look for the email | 16:44 | |
| ignas | though - what specific fields we will have is not really affecting the work we will be doing | 16:45 |
| th1a | Let's just say I should show up with a final list? | 16:45 |
| ignas | yeah | 16:45 |
| th1a | OK. | 16:46 |
| th1a | aelkner: Do you have any specific questions about the sprint right now? | 16:47 |
| aelkner | i haven't been thinking about it yet, so no | 16:47 |
| aelkner | i figured i'd get up to speed a couple of days before | 16:47 |
| aelkner | an ask any question then | 16:48 |
| th1a | OK. | 16:48 |
| th1a | Anything else ignas? | 16:48 |
| ignas | not really | 16:50 |
| th1a | aelkner: What's up? | 16:50 |
| aelkner | so i got the sla package to work with schoolyears | 16:51 |
| aelkner | i tried to deploy to sla this weekend, but i ran into the url problem ignas just mentioned | 16:51 |
| aelkner | so they are still usign the older version | 16:51 |
| aelkner | i could use the new url tonight | 16:51 |
| aelkner | so that's what i'll do there | 16:52 |
| aelkner | i also "chewed" on you report card document | 16:52 |
| aelkner | i figured i'd work on that this week | 16:52 |
| th1a | It is really similar to what we did at SLA, right? | 16:52 |
| aelkner | i have to admit, i'm a bit confused about what you want there | 16:53 |
| th1a | Well, I'm saying work backwards from the SLA report cards we did. | 16:53 |
| th1a | It is essentially just creating a formal way to do that. | 16:53 |
| aelkner | ok, so i get that we faciilitate creating a single worksheet | 16:54 |
| aelkner | for every section and prepopulating it with activities like we did manually at SLA | 16:55 |
| aelkner | i'm just not sure about the concepts of term, grading period | 16:55 |
| aelkner | that you mentioned in the document | 16:55 |
| th1a | Well, terms are terms. | 16:56 |
| th1a | That is... | 16:56 |
| th1a | Terms correspond to the length of time courses meet. | 16:56 |
| th1a | Like semesters or years. | 16:56 |
| th1a | But there are often interim grades, like quarterly grades. | 16:57 |
| th1a | So the manager can either set up one reportsheet for all the constituent interim grades and the final term grade, | 16:57 |
| th1a | or do separate sheets for each interim report. | 16:58 |
| th1a | Which works better will probably be more clear once we've got the report card setup done. | 16:58 |
| ignas | term defines the lifetime of the section, grading period defines the grading periods (you can have some kind of aggregate grade more than once every term) | 16:58 |
| ignas | point is - in a term, section does not change | 16:59 |
| ignas | while when the term ends - the sections might disappear completely | 16:59 |
| th1a | Yes. | 16:59 |
| th1a | Make sense? | 17:00 |
| aelkner | in doing my sla schoolyears work i went over the term package | 17:00 |
| aelkner | i saw this concept of sub-terms for grading periods | 17:00 |
| aelkner | i wasn't sure what to make of it | 17:00 |
| ignas | sub-terms ? | 17:01 |
| ignas | where? | 17:01 |
| aelkner | look at the tests for schooltool.term | 17:01 |
| aelkner | you create a term and call it "year" | 17:02 |
| ignas | hmm, maybe there still is the old README.txt by srichter | 17:02 |
| aelkner | not a README.txt | 17:02 |
| th1a | I wonder if they run? | 17:02 |
| ignas | aelkner: can you point me at the specific place | 17:03 |
| aelkner | i'm looking | 17:03 |
| ignas | imho - grading periods should be managed by the gradebook code | 17:04 |
| aelkner | pardon me, it was in README.txt | 17:04 |
| ignas | i'll delete it | 17:04 |
| aelkner | are ytou saying stephan wrote that? | 17:04 |
| ignas | yeah, stephan and th1a | 17:04 |
| aelkner | ooh | 17:05 |
| ignas | frankly - i'll review it, salvage useful parts and then delete it | 17:05 |
| ignas | it even mentions FHS | 17:05 |
| ignas | and i don't think it ever "ran" | 17:05 |
| aelkner | no wonder it doesn't get run | 17:05 |
| ignas | it was more of a design Sci-Fi | 17:05 |
| aelkner | hehe | 17:05 |
| aelkner | so i'll get my head out of that paradigm | 17:05 |
| th1a | Please. | 17:06 |
| aelkner | so terms are the atomic unit in which a given section lives | 17:06 |
| ignas | yep | 17:06 |
| aelkner | and grading periods are just an arbitrary designation | 17:06 |
| ignas | and gradebook can assign "grading periods" to a pair of "term + section" or just to a "term" in some way it wants | 17:06 |
| th1a | Hm? | 17:07 |
| ignas | but that's completely for the gradebook to do, maybe in schooltool.grading_periods, or schooltool.gradebook.periods for easier reuse between gradebooks | 17:07 |
| aelkner | but grading periods as a concept would only live in schooltool.gradebook, right? | 17:07 |
| ignas | yeah | 17:07 |
| aelkner | ah, i see | 17:07 |
| th1a | My point is they only have to exist as columns in a reportsheet. | 17:07 |
| th1a | At this point they don't really formally exist in SchoolTool. | 17:08 |
| ignas | yeah, it is doable without any new data structures I guess | 17:08 |
| th1a | They probably will eventually, but it isn't necessary. | 17:08 |
| aelkner | that simplifies things | 17:08 |
| aelkner | i still need a new data structure | 17:08 |
| th1a | This is the difference between th1a in 2009 and th1a in2005. | 17:08 |
| ignas | like naming worksheets "GP1", "GP2" and "GP3" and assign them to the section | 17:09 |
| aelkner | with baby/without baby | 17:09 |
| th1a | Oh, that too. | 17:09 |
| jstraw | no... th1a.2009 has learned enough about how software development works | 17:09 |
| aelkner | but you still want grading periods to be represented by their own worksheets, right? | 17:10 |
| jstraw | to know that not everything needs to be overengineered | 17:10 |
| th1a | I'm saying at this point grading periods don't necessarily need their own worksheet, because in many cases it would just be a 1 column worksheet. | 17:10 |
| ignas | aelkner: I don't know that really, as I don't really "grok" how US grading works | 17:10 |
| th1a | So they could be columns in a single worksheet. | 17:11 |
| aelkner | like the "report card" worksheet | 17:11 |
| th1a | The standard way of doing grading at higher grades is just a letter A-F. Maybe a plus or minus too. | 17:11 |
| th1a | But there are a zillion variations. | 17:11 |
| ignas | i guess just writing up a sample report and thinking of the wsheets/activities as a way to enter the data into the report might help me understand it | 17:11 |
| th1a | The default worksheet for a high school semester would have these column headers: 1st 2nd Final. | 17:12 |
| th1a | And an A-F score system. | 17:12 |
| th1a | But you might have an arbitrarily more complicated system. | 17:13 |
| aelkner | now when you talk about a semester, you mean a term in schooltool, right? | 17:13 |
| th1a | Yes, semesters are terms, because some sections end at the end of a semester. | 17:14 |
| aelkner | since this use of terms is still theoretical (cando and sla don't have more than one tem yet) | 17:14 |
| aelkner | i still need time to get into the swign of thinking about terms that way | 17:14 |
| th1a | It doesn't make much difference in this case. | 17:15 |
| aelkner | i can see that | 17:15 |
| aelkner | i just need to allow them the overhanging control of a given term | 17:16 |
| th1a | Hm? | 17:16 |
| aelkner | to be able to enter grading period data and final grades data | 17:16 |
| aelkner | into this one wrksheet | 17:16 |
| aelkner | that we automatically create for them, | 17:17 |
| aelkner | at their behest | 17:17 |
| th1a | We don't really care what goes into one or more reportsheets the manager creates. | 17:17 |
| aelkner | we need to allow the user to choose | 17:18 |
| th1a | Right. | 17:18 |
| th1a | They can call it whatever they want and use any score system. | 17:18 |
| th1a | It can be "Received Flu Vaccine" (y/n). | 17:19 |
| aelkner | can we leverage the existing objects, Worksheet, and Activity to do this? | 17:19 |
| th1a | That's kind of the idea. | 17:19 |
| aelkner | i have this picture in my head | 17:19 |
| th1a | The main thing is you need a worksheet that teachers can't delete or modify. | 17:19 |
| aelkner | of teh administrator creating a "dummy" section | 17:20 |
| aelkner | and putting the worksheet/activities there | 17:20 |
| aelkner | then asking the system to propagate that to all other sections in the term | 17:20 |
| aelkner | i say "dummy" section | 17:21 |
| aelkner | because worksheet/activity creation all relies on the existence of a section | 17:21 |
| th1a | You probably need a special container. | 17:21 |
| aelkner | a special container of sections that are isolated from the "real" sections? | 17:22 |
| jstraw | I don't see why this couldn't be a part of the section's gradebook | 17:23 |
| aelkner | jstraw: have you read tom's document? | 17:23 |
| jstraw | I was never sent it | 17:23 |
| aelkner | it was posted to schooltool mailing list | 17:23 |
| jstraw | *looks again* | 17:23 |
| aelkner | so definitely we can assume that the admistrator is working with a "dummy" section | 17:24 |
| th1a | No... the administrator goes to a special container to create the reportsheets. | 17:24 |
| aelkner | worksheets go in sections | 17:24 |
| aelkner | so we'll need a dummy one at least | 17:24 |
| aelkner | everything in schooltool.gradebook is registered against ISection | 17:25 |
| aelkner | so let's depart from understanding that | 17:25 |
| ignas | aelkner: well - you can change that, can't you? | 17:25 |
| th1a | I'm thinking that creating a dummy section will create all kinds of weirdness and exceptions. | 17:26 |
| aelkner | perhaps if i created a marker interface | 17:26 |
| aelkner | adn marked sections with that interfaces | 17:26 |
| aelkner | then changed schooltool.gradebook to work of the marker interface rther then ISection | 17:27 |
| ignas | do you really want to define reportcards using existing data sstructures | 17:27 |
| ignas | instead of adding a simple "defintion object" | 17:27 |
| ignas | and using that to create the actual worksheets + activities for other sections | 17:27 |
| th1a | Ah. Yes, that might make more sense. | 17:28 |
| aelkner | for instance | 17:28 |
| aelkner | we have an index.html view of a worksheet | 17:28 |
| aelkner | that delivers the gradebook | 17:28 |
| aelkner | it assumes that the worksheet is for a "section" | 17:29 |
| aelkner | otherwise, what students would it grade? | 17:29 |
| aelkner | perhaps, we could have a new object | 17:29 |
| aelkner | called ReportSheet | 17:29 |
| aelkner | that doesn't get graded, so it doesn't need a section attached to it | 17:30 |
| aelkner | but still can hold activities | 17:30 |
| th1a | It just defines the columns. | 17:30 |
| th1a | Yes. | 17:30 |
| aelkner | so the UI would look like the "manage" view of the worksheet | 17:30 |
| * ignas thought you were doing that already | 17:30 | |
| aelkner | i haven't started anything yet, so it's kind of hard to have "done" anything | 17:31 |
| ignas | i mean - 2 separate things - list of students and list of activities | 17:31 |
| ignas | i mean - 3 separate things - list of students and list of activities and an object that combines both for grading + presentation | 17:31 |
| aelkner | the gradebook object is a proxy | 17:32 |
| aelkner | it combines the worksheet and the section's members | 17:32 |
| aelkner | but | 17:32 |
| th1a | presentation to the teacher or generating the final report? | 17:32 |
| aelkner | the worksheet belongs to the section | 17:32 |
| aelkner | it is an annotation of it | 17:32 |
| aelkner | but Reportsheets dpn't need to be | 17:32 |
| th1a | If the ReportSheet is just the definition of the activities. | 17:33 |
| th1a | The teachers can be filling out more or less regular worksheets. | 17:33 |
| th1a | If we add a "read-only" flag. | 17:34 |
| aelkner | can we agree that: | 17:34 |
| aelkner | 1) | 17:34 |
| th1a | That is read-only the activity definitions, not the scores. | 17:34 |
| aelkner | 1) ReportSheets go in a separate place, a new folder as th1a suggested before | 17:35 |
| aelkner | 2) they contain Activities | 17:35 |
| aelkner | 3) at any time, the administrator can request that a given ReportSheet get | 17:35 |
| aelkner | propagated to all the sections | 17:35 |
| aelkner | that action would cause real Worksheets to get created in the sections | 17:36 |
| th1a | ok... | 17:36 |
| ignas | no difference really, as long as you have full functional tests that th1a agrees with ;) | 17:36 |
| ignas | and they are passing with the code | 17:36 |
| th1a | That sounds sensible. | 17:37 |
| aelkner | i like the sound of this | 17:37 |
| ignas | defining the UI before code would be kind of nice, as not to do insane UI decisions just for the sake of saving a couple of lines ;) | 17:37 |
| aelkner | i think ican get started this week from what i understand now | 17:37 |
| th1a | Just so we're on the same page -- the next step then is that the manager maps ReportSheet columns to columns in the printed report card. | 17:37 |
| aelkner | ok, so let's discuss that | 17:38 |
| th1a | So we have to have consistent id's, or something across the reportsheet and all the reporting worksheets. | 17:38 |
| aelkner | would we be able to reuse an attribute in an activity for that purpose? | 17:38 |
| aelkner | or would i need a new object called ReportActivity | 17:39 |
| aelkner | to go with ReportSheet? | 17:39 |
| th1a | Hm? I'm thinking just saying "Q1" in report sheet "Grades" should be the first column in the term report card grid. | 17:39 |
| th1a | Or whatever. | 17:40 |
| aelkner | huh? | 17:40 |
| th1a | Your report card is going to be a grid. | 17:40 |
| th1a | For each kid, the row will be a section. | 17:40 |
| th1a | The columns will be activities from ReportSheets. | 17:40 |
| th1a | The manager will just have to define which ones they are. | 17:41 |
| aelkner | ah, so some of the activities in a given ReportSheet will not make it into the report card pdf report? | 17:41 |
| th1a | One would imagine they all will, but not necessarily. | 17:42 |
| aelkner | i'm trying to think how we can leverage the objects we already have to do this | 17:43 |
| th1a | I'm not sure what you mean. | 17:44 |
| * th1a drops the bag of gravel... | 17:44 | |
| aelkner | right in the middle of our discussion, how rude | 17:45 |
| th1a | keep going... | 17:45 |
| aelkner | just kidding | 17:45 |
| aelkner | anyway, we have this Requirement object | 17:45 |
| aelkner | it's the ordered container that we like having and use for worksheets | 17:46 |
| th1a | Perhaps we can use object references instead of ids? | 17:46 |
| aelkner | ReportSheets can be derived from that as well | 17:46 |
| aelkner | yeah, i definitely didn't like he id concept | 17:46 |
| aelkner | we just removed them from the forms, remember? | 17:47 |
| aelkner | they only case he user to get confused | 17:47 |
| aelkner | cause | 17:47 |
| th1a | Well, you might get collisions, too. | 17:47 |
| aelkner | if we had ReportSheets contain Activity objects | 17:48 |
| aelkner | or better yet | 17:48 |
| aelkner | ReportSheets contain ReportActivity objects | 17:48 |
| aelkner | ReportActivity objects are activities with one more attribute | 17:49 |
| aelkner | 'use in report card' y/n | 17:49 |
| aelkner | then we could have an add/edit view that looks just like the add/edit activity view | 17:49 |
| th1a | Hm... I don't know. | 17:50 |
| aelkner | but with just the one additional attribute | 17:50 |
| th1a | Yes, but laying out the report card is the hard part. | 17:50 |
| th1a | That's not the part to skimp on. | 17:50 |
| aelkner | ok, so maybe trying to leverage IActtivity is not the answer | 17:51 |
| aelkner | perhaps ReportActivities are new objects | 17:51 |
| aelkner | that are similar to activities | 17:52 |
| aelkner | in that they have a score system | 17:52 |
| aelkner | but otherwise, they have other attributes that make them quite different | 17:52 |
| aelkner | things that would allow for layout issues | 17:52 |
| aelkner | enable/disable | 17:53 |
| th1a | I don't think the ReportActivity has to know anything about how it is being used in a report. | 17:53 |
| th1a | That's a view issue. | 17:53 |
| aelkner | but the admin person needs a way to tell the view how to work | 17:53 |
| th1a | Are we talking about the report card the parent will see or the worksheet the teacher will fill out? | 17:54 |
| aelkner | the first one | 17:54 |
| th1a | Laying out the report card will be a pretty separate process. | 17:54 |
| aelkner | need a five minute break, be right back | 17:55 |
| th1a | The important part is that when the manager says "1st quarter grade" is the first column in the report card, the system has to be able to iterate through each section of the term and each student and retreive the "1st quarter grade." | 17:55 |
| th1a | That is assuming that "1st quarter grade" was in the ReportSheet and on each teacher's report worksheet. | 17:56 |
| * jelkner leaves for class | 17:57 | |
| *** jelkner has quit IRC | 17:57 | |
| jstraw | I guess my question on all of this is... is there any reason for this ReportSheet to have anything but a set of dates and a grading scale? | 17:58 |
| jstraw | The dates correspond to the days where reports close | 17:59 |
| jstraw | and the grading scale takes numbers to whatever the schools scale is | 17:59 |
| jstraw | then you attach it to a gradebook and it reads due dates off all the existing activities | 17:59 |
| jstraw | and poof you have a populated report sheet | 17:59 |
| th1a | jstraw: There are lots of different kinds of grading systems. | 17:59 |
| jstraw | th1a: so you let the teacher write the scale | 18:00 |
| jstraw | with override from the admin | 18:00 |
| jstraw | I just don't see why we need to duplicate any data at all | 18:00 |
| jstraw | we just need something that screws with existing gradebook data | 18:00 |
| th1a | We don't really want that much magic at this point. | 18:01 |
| th1a | Because everyone will want different magic. | 18:01 |
| th1a | Also, particularly in, say, an elementary school, you want lots of stuff that doesn't correspond to regular gradebook grades at all. | 18:02 |
| th1a | "Works well with others." | 18:02 |
| th1a | Etc. | 18:02 |
| jstraw | th1a: well, lets balance magic with focus and work duplication | 18:03 |
| jstraw | APS for sure uses *totally* different report cards between ES and HS | 18:04 |
| jstraw | I've seen both | 18:04 |
| jstraw | in fact, at HS the grade is a single number 0-100 | 18:04 |
| jstraw | exported from the teachers gradebook at grade close | 18:05 |
| jstraw | in ES... teachers have to fill out a web form for every student | 18:05 |
| th1a | We'll let you import grades from other worksheets -- it just isn't going to be the default. | 18:05 |
| jstraw | th1a: if we're going to play import games | 18:05 |
| jstraw | why not just tack it onto a gradebook to start | 18:05 |
| jstraw | and have them create a ReportSheet for each period | 18:06 |
| jstraw | (even if it is 1 for the entire term) | 18:06 |
| th1a | I want to leave it flexible. | 18:07 |
| aelkner | th1a: i'm back | 18:11 |
| aelkner | so am i right in assuming that we need two sets of objects | 18:11 |
| aelkner | the first being a set of activities stored in a ReportSheet for propagation to sections | 18:12 |
| aelkner | the second being for report card layout | 18:12 |
| aelkner | where activities are selected/deselected for appearance in the report? | 18:13 |
| th1a | Report card layout is an entirely separate issue. | 18:13 |
| jstraw | layout is a global | 18:13 |
| th1a | As long as we can retrieve the scores. | 18:14 |
| jstraw | yea | 18:14 |
| th1a | For the purpose of our own sanity, let's not try to figure out report card layout now. | 18:14 |
| * jstraw agrees with th1a | 18:14 | |
| aelkner | it sounded like you waned the user to be able to design the layout | 18:14 |
| jstraw | and I feel compelled to bring up aelkner's favorite topic as a reminder when we get there | 18:14 |
| jstraw | a reports system | 18:14 |
| jstraw | aelkner: not the user | 18:15 |
| jstraw | the school administration should have some control over the header | 18:15 |
| aelkner | that's the user i'm referring to | 18:15 |
| jstraw | but that's not for now either | 18:15 |
| th1a | yvl wrote a custom header already (although I haven't seen it). | 18:15 |
| aelkner | it's a png file, that's all | 18:16 |
| th1a | We can go over it with him this weekend. | 18:16 |
| aelkner | true | 18:16 |
| aelkner | but the main issue is when you talk of 'flexibility" | 18:16 |
| aelkner | what that means is the user chooses | 18:16 |
| aelkner | that requires a persistent object that contains the user's choices | 18:16 |
| aelkner | that is then applied at the time of report creatoion | 18:17 |
| aelkner | creation | 18:17 |
| * th1a is trying not to get into that. | 18:17 | |
| th1a | I'm just saying, in case it isn't obvious, that we need to be able to retrieve the data from the report worksheets reliably. | 18:17 |
| aelkner | of course we need that | 18:17 |
| aelkner | that goes without saying | 18:18 |
| th1a | OK. | 18:18 |
| th1a | Good. | 18:18 |
| aelkner | if we forgo the user custom layout question for now | 18:18 |
| aelkner | we are left with ReportSheets that contain Acivitiy objects | 18:18 |
| aelkner | and an automated propagation to sections at the user's request | 18:19 |
| aelkner | and a report card pdf | 18:19 |
| aelkner | that jsut knows how to layout the report | 18:19 |
| aelkner | and uses the ReportSheet object to see which activities are involved | 18:20 |
| aelkner | which in turn allows the report to find the grades in the sections | 18:20 |
| th1a | Yes. | 18:20 |
| aelkner | so, the user never should choose ids as we have come to realize | 18:21 |
| aelkner | but the ids are something that we could keep consistent | 18:21 |
| aelkner | between the ReportSheet activities | 18:21 |
| aelkner | and the gradebook activities that get propagated | 18:22 |
| jstraw | Report Cards do not show Activities | 18:22 |
| aelkner | if the propagation action creates a new worksheet in each section | 18:22 |
| jstraw | Progress Reports do | 18:22 |
| th1a | Unless we want to use some other kind of object references. | 18:22 |
| jstraw | A Report Card would show all of a students grades for the sections they are in for that term/grading period | 18:22 |
| th1a | jstraw: Don't confuse aelkner. | 18:22 |
| jstraw | th1a: not trying to | 18:23 |
| aelkner | an activity found in a ReportSheet can in now way know the object reference | 18:23 |
| th1a | The report card shows whatever the manager says it shows. | 18:23 |
| aelkner | of an activity found in a section | 18:23 |
| jstraw | th1a: and that will be? | 18:23 |
| aelkner | jstraw: please don't interrupt | 18:23 |
| aelkner | i mean, the things you're asking are for another thread | 18:24 |
| th1a | jstraw: The more automagical parts you want will be added later. | 18:24 |
| aelkner | i'm still trying to work out the technical side | 18:24 |
| aelkner | which objects are created and how they would be used | 18:24 |
| aelkner | so th1a | 18:24 |
| jstraw | th1a: ok, I just want to make sure that our image of a report card is what SLA and Jeff are going to need | 18:24 |
| aelkner | i think th1a sees the image of teh report card as being a view | 18:26 |
| aelkner | that could be different depending on how the school wants it to look | 18:26 |
| aelkner | but that the data needs to come from the same place regardless of the view | 18:27 |
| aelkner | does that make sense? | 18:27 |
| aelkner | th1a: ? | 18:28 |
| th1a | I think so. | 18:28 |
| aelkner | i mean we can worry about presentation later as long as we have the data model right | 18:29 |
| aelkner | so what i was saying was this: | 18:29 |
| aelkner | the admin user creates a ReportSheet that hangs off of the term object | 18:30 |
| aelkner | just as the worksheets hang off of the section object | 18:30 |
| aelkner | the admin user puts activities in there | 18:30 |
| aelkner | the propagation request causes a worksheet to be created in all sections | 18:31 |
| th1a | y | 18:31 |
| aelkner | populated by those activies | 18:31 |
| aelkner | using the same ids that were created automatically (Names chooser) | 18:31 |
| aelkner | when creating the report sheet activities | 18:31 |
| aelkner | that way we can line them up at any time in the future | 18:32 |
| aelkner | or even request that an activity is suppressed? | 18:32 |
| aelkner | during report card pdf cration? | 18:32 |
| aelkner | but that's the part that i was getting to when i said we would need another object | 18:33 |
| th1a | Yes. | 18:33 |
| aelkner | if the admin user wants to control what data is presented | 18:33 |
| aelkner | we would need to have an object persisted with those choices | 18:33 |
| th1a | Note that the report card will probably pull from other sources as well, like the attendance journal. | 18:33 |
| th1a | But yes, the report card description is an object itself. | 18:34 |
| aelkner | i could then, in theory, break the work up into creating the ReportSheets and the propagation action | 18:35 |
| th1a | Yes. | 18:35 |
| aelkner | and we discuss the report control at the sprint | 18:36 |
| th1a | This seems pretty easily broken into chunks. | 18:36 |
| th1a | Yes. | 18:36 |
| aelkner | i like the sound of that | 18:36 |
| aelkner | ignas: are you still there? | 18:36 |
| ignas | yes | 18:36 |
| aelkner | what do you think of the idea of having the ReportSheets go in a folder that is an annotation of the term | 18:36 |
| aelkner | just as the workheets are annotations of the section | 18:37 |
| ignas | well - you know what I think of annotations in general | 18:37 |
| aelkner | that would be consistent | 18:37 |
| aelkner | not really | 18:37 |
| ignas | annotations are bad | 18:37 |
| aelkner | that's a statement of judgement, hardly technical in nature | 18:37 |
| ignas | annotations are a major source of trouble when doing some evolution steps | 18:38 |
| ignas | because as you are putting objects into terms for example | 18:38 |
| ignas | if i will be updating terms i might have to "know" about what's in it's annotations | 18:38 |
| aelkner | you jsut copy them | 18:38 |
| ignas | which has caused a lot of troubles with Person -> BasicPerson migration | 18:38 |
| aelkner | you should "know" what's in them | 18:39 |
| aelkner | they shouldn't be changed, so what's to know? | 18:39 |
| ignas | yeah, so if i am implementing a term i should know about gradebook? | 18:39 |
| ignas | if any object in annotations is refering to the object being annotated directly | 18:39 |
| ignas | like calendar and a lot of other things in annotations did | 18:39 |
| ignas | i must update the reference | 18:39 |
| ignas | also - copying annotations sometimes triggers subscribers (also a problem) | 18:40 |
| ignas | like "oh you have deleted the calendar of a person" "and added it to another person" | 18:40 |
| aelkner | i didn't think of that one | 18:40 |
| aelkner | but think of this | 18:40 |
| ignas | but - as long as you are sure I can replace Terms with Glorks - you can do that ;) | 18:41 |
| aelkner | even if one doesn't use annotations | 18:41 |
| aelkner | you still still have the dependcy | 18:41 |
| ignas | int ids are a safer way to "bind" objects to each other in my opinion | 18:41 |
| ignas | at least it was easier for me to manage | 18:41 |
| aelkner | you can't just go moving a term and not take into account the dependency that schooltool.gradebook has | 18:41 |
| ignas | though - it's up to you really, I just prefer not keeping objects on other objects, as that also makes us very dependent on ZODB | 18:42 |
| aelkner | no matter how that dependency is implemented | 18:42 |
| ignas | i can postpone it | 18:42 |
| ignas | for another evolution script in schooltool.gradebook | 18:42 |
| aelkner | how could we not be dependent on the ZODB? | 18:42 |
| aelkner | everything we do is tied to it | 18:42 |
| ignas | well - we can have it "YOU CAN'T HAVE STUFF NOT IN ZODB OR EVERYTHING WILL FALL" | 18:42 |
| th1a | Storm! | 18:42 |
| ignas | or "with some work you can have persons stored in sql database and it will work fine: | 18:43 |
| ignas | and i'd rather pick the later one ;) | 18:43 |
| aelkner | that would have to be handled with proxies anyway | 18:43 |
| ignas | yeah, proxies are not persistent | 18:44 |
| aelkner | and i have no idea how you envision that | 18:44 |
| ignas | i just like separating data that belongs to different modules into different places in zodv | 18:44 |
| ignas | zodb | 18:44 |
| aelkner | so to be fair, it's a 'i prefer' issue rather than 'i't bad' | 18:44 |
| ignas | so app["schooltool.terms"] has terms, and that's it, and app["schooltoo.gradebook"] has gradebooks, it makes it easier for me to understand the data model | 18:45 |
| ignas | as really - if I can't recall | 18:45 |
| ignas | what kinds of things are stored on a person | 18:45 |
| ignas | in person annotations | 18:45 |
| ignas | how can I expect anyone else to do it? | 18:45 |
| aelkner | we keep evaluations ther | 18:45 |
| aelkner | what you're saying is you hate the way schooltool.gradebook works | 18:46 |
| aelkner | and what's more you don't like any of stephan's coding methods | 18:46 |
| aelkner | use of annotations | 18:46 |
| ignas | yes, i find it very difficult to understand without reading a lot of code | 18:46 |
| aelkner | use of README.txt for tests | 18:46 |
| aelkner | i think that's a larger issue, but mind is open | 18:46 |
| ignas | while with for example sections I can say | 18:46 |
| ignas | "sections are in app['schooltool.sections']" | 18:47 |
| ignas | section.__name__ is the int id of the term section belongs to | 18:47 |
| ignas | and that's it | 18:47 |
| aelkner | see, i find that part confusing, but i will live with it | 18:48 |
| ignas | ok, in ZODB | 18:48 |
| ignas | can you tell me where is a grade stored | 18:48 |
| ignas | when you write "F" | 18:48 |
| aelkner | yes | 18:48 |
| ignas | to someone on some activity in some section | 18:48 |
| ignas | tell me | 18:48 |
| aelkner | all is stored in the annotations of the person | 18:48 |
| ignas | app['persons']['john'] | 18:48 |
| ignas | what's then | 18:49 |
| ignas | app['persons']['john'].__annotations__ | 18:49 |
| aelkner | grade 'F' of activity 'Quiz 1' for section 'Math' | 18:49 |
| ignas | yeah, but where | 18:49 |
| ignas | app['persons']['john'].__annotations__['schooltool.gradebook'] ? | 18:49 |
| aelkner | yes | 18:50 |
| ignas | and what's then? | 18:50 |
| aelkner | there is found a tuple | 18:50 |
| ignas | i mean what objects, what keys | 18:50 |
| ignas | i mean - i don't know, so could you write the full "code" to get the information | 18:50 |
| ignas | without adapters | 18:50 |
| aelkner | iKeyReference(section), IKeyReference(activity) --> score | 18:50 |
| aelkner | i don;'t understand you question | 18:51 |
| ignas | print app['persons']['john'].__annotations__['schooltool.gradebook'][id of section, id of activity] | 18:51 |
| aelkner | of course there's code to get the scores | 18:51 |
| ignas | would print me "F" | 18:51 |
| aelkner | yes | 18:52 |
| ignas | aelkner: i know, but you do know that you can't and should not use adapters in evolution scripts | 18:52 |
| ignas | except in such cases like IKeyReference | 18:52 |
| aelkner | so who's using adapters? | 18:52 |
| ignas | "of course there's code to get the scores" | 18:53 |
| ignas | og | 18:53 |
| ignas | oh | 18:53 |
| ignas | and it seems that it's not "F" in there | 18:53 |
| ignas | it's an Evaluation object | 18:53 |
| aelkner | true | 18:53 |
| aelkner | and the problem is? | 18:54 |
| ignas | and Evaluation object is referring to Person who wrote the grade | 18:54 |
| ignas | or not? | 18:54 |
| aelkner | yes, it is | 18:54 |
| ignas | i mean - what is evaluation? | 18:54 |
| ignas | evaluator | 18:54 |
| aelkner | yep | 18:54 |
| aelkner | the teacher | 18:54 |
| ignas | the problem is that if I will want to replace BasicPerson with NewPerson | 18:54 |
| ignas | for example | 18:54 |
| ignas | i will have to update all the evaluation objects (that I have no clue about as I am working on a person module) | 18:55 |
| ignas | making people know and care about the code that they did not write, and are not modifying is a bad idea ine general, which is why i want data as separated as sanely possible | 18:56 |
| aelkner | you need to know about schooltool.gradebook when working on schooltool | 18:56 |
| aelkner | there's no way around that | 18:56 |
| ignas | someone working on gradebook should not care about schooltool.calendar | 18:56 |
| ignas | there is a way around that | 18:56 |
| ignas | someone working on schooltool.person should not know all the possible plugins out there | 18:56 |
| aelkner | schooltool.gradebook is not a plugin in reality | 18:57 |
| ignas | because if there is 1 gradebook, then there will be 3 gradebooks, and If I will have to know about all of them and how they work | 18:57 |
| aelkner | it | 18:57 |
| th1a | Once upon a time stevea had a master plan for all this... | 18:57 |
| ignas | i will not be able to work on it | 18:57 |
| ignas | which is why I want to limit ways in which parts of the system are reffering to each other to: | 18:57 |
| ignas | ids of objects | 18:57 |
| ignas | relationships | 18:57 |
| ignas | as that makes it more manageable | 18:58 |
| ignas | as I know that if I will keep the same IntId - everything connected to the person | 18:58 |
| aelkner | relationships ARE annotations | 18:58 |
| ignas | will keep on working as it used to | 18:58 |
| ignas | yes, but I know about relationships | 18:58 |
| ignas | and it is sane to want people working on schooltool | 18:58 |
| ignas | to understand relationships | 18:58 |
| ignas | it's not so sane to want them to know attendance, gradebook, notes, calendars, journal, cando etc. | 18:59 |
| ignas | if all they want to do is change groups to have 2 different types | 18:59 |
| aelkner | i don't see how you can imagine making a sweeping change to a core aspect of schooltool | 19:00 |
| aelkner | and not realize its impact on plugins | 19:00 |
| aelkner | you recall you changed schooltool to use schoolyears | 19:00 |
| aelkner | and that didn't impact cando/sla? | 19:00 |
| aelkner | or course it did | 19:00 |
| ignas | yeah, but aspect being core does not make changes "core' | 19:00 |
| ignas | i have changed the *way* the system works | 19:00 |
| ignas | not just modified a couple of properties of the system to suite me | 19:01 |
| aelkner | yeah, it was a major change to be sure | 19:01 |
| aelkner | not one entered into lightly | 19:01 |
| aelkner | anyway, what you're talking about is philosophical, and i'm sure i could be convinced to agree | 19:02 |
| aelkner | but the practical fact is that we have annotations everywhere | 19:02 |
| aelkner | we would need an overhaul of the data model to fix that | 19:03 |
| ignas | yeah, another fact is - that I am slowly moving everything from annotations to other places | 19:03 |
| ignas | which is easier to do | 19:03 |
| ignas | if no new stuff is being added ;) | 19:03 |
| aelkner | that brings us back to your original response to my suggestion about annotating the term | 19:05 |
| ignas | i'd rather you do it the way that i have suggested multiple times, otoh - you will be maintaining it, so if you are finding it difficult to understand "objects for something kept in a top level container" just do it the way you understand and can manage | 19:06 |
| aelkner | not annotating the term would mean having two types of solutions to the same problem | 19:06 |
| aelkner | the existing one with annotation on sections | 19:06 |
| aelkner | and the new one with a new container for ReportSheets by term | 19:07 |
| ignas | you see - from the usage point | 19:07 |
| ignas | the API is identical | 19:07 |
| ignas | the only difference is - the adapter that gets the data | 19:07 |
| jstraw | you two have fun | 19:07 |
| jstraw | I'll be back in a while | 19:07 |
| *** jstraw has quit IRC | 19:08 | |
| ignas | which is why I find it difficult to understand why does it matter so much to you where to put it | 19:08 |
| aelkner | it doesn't matter to the API | 19:08 |
| aelkner | but code design and complexity does matter to the developer | 19:08 |
| ignas | i mean - where it will be, matters to me because of all the evolution scripts, but to you it only changes the code for 1 adapter | 19:08 |
| ignas | yeah | 19:08 |
| ignas | the complexity is concentrated in 1 adapter | 19:08 |
| ignas | and that's it, 10 lines of code, maybe 15 | 19:08 |
| aelkner | it's not a question of lines of code but of the brain cycles required to keep two different data models | 19:09 |
| aelkner | in one's head at the same time | 19:09 |
| ignas | why keep them? | 19:09 |
| ignas | you write it, you forget it | 19:09 |
| ignas | that's the point of adapters | 19:10 |
| aelkner | i don't forget what i write | 19:10 |
| ignas | and abstractions in general | 19:10 |
| ignas | but yeah - for you it's more convenient thinking "grades are in persons" | 19:10 |
| ignas | and for me it's more convenient thinking "gradebook data is in app['schooltool.gradebook']" | 19:10 |
| aelkner | just so you understand, i have no problem with your design here | 19:11 |
| ignas | because else i get - grades in persons + report sheets in terms + activities in app + worksheets in sections | 19:11 |
| aelkner | i just have to deal with the way the code/data model already is | 19:11 |
| ignas | yeah, i know | 19:11 |
| aelkner | i like the idea of usign the containers | 19:11 |
| aelkner | i did so with sla.demographics with no problem | 19:11 |
| aelkner | but that was my code, not legacy | 19:12 |
| ignas | well - my approach is | 19:12 |
| aelkner | unfortunately, schooltool.gradebook is now old enough to be "legacy" | 19:12 |
| ignas | fix legacy code when you can, and when you can't - at least do not increase the problems it has created ;) | 19:12 |
| ignas | but yeah, i can understand the | 19:13 |
| ignas | "let's have it one way in one place" | 19:13 |
| ignas | so yeah, if it is more convenient for you to fix such things in one go | 19:13 |
| ignas | just do that | 19:13 |
| * ignas does not really get the time to fix *anything* in one go | 19:13 | |
| aelkner | thanks, you understand my point noe | 19:13 |
| ignas | which is why I do it while "passing by" | 19:13 |
| aelkner | now | 19:13 |
| ignas | i mean - i was against some faassen's changes to the code | 19:14 |
| aelkner | we will need to right evolution scripts to move evaluations out of the preson object | 19:14 |
| ignas | because he was "adding one more system of doing stuff" | 19:14 |
| aelkner | fassen's changes? which changes? | 19:15 |
| ignas | when he did demographics person | 19:15 |
| aelkner | ah | 19:15 |
| aelkner | so yeah, you get my point about not proliferating complexity | 19:15 |
| aelkner | but i get yours on the use of containres | 19:15 |
| ignas | what i found interesting is | 19:16 |
| ignas | grades in persons | 19:16 |
| ignas | in lyceum.journal | 19:16 |
| ignas | i have it "grades in sections" | 19:16 |
| ignas | with "evaluated person" as an attribute | 19:16 |
| ignas | instead of "evaluated section" as an attribute | 19:17 |
| ignas | both work | 19:17 |
| aelkner | and you have a separate container, right? | 19:17 |
| ignas | yeah, journal objects are in app['schooltool.lyceum.journal'][section_int_id] | 19:18 |
| aelkner | so say, at some time in the future, i'm able to tackle the issue of moving all gradebook data to a new folder | 19:18 |
| ignas | this has the benefit of keeping "list of activities" and "list of grades" in one place | 19:18 |
| ignas | while if i had persons -> grades and sections -> timetable events (activities) | 19:19 |
| ignas | i'd need 2 containers | 19:19 |
| ignas | for each of these | 19:19 |
| th1a | How long would it take to make that move? | 19:19 |
| aelkner | this would require overhauling schoolool.gradebook code (not difficult, and certainly a good opportunity to clean up) | 19:19 |
| aelkner | butalso | 19:19 |
| aelkner | there would be the need to evolve the data | 19:20 |
| ignas | th1a: I am not sure it would be worth the effort at the moment, it probably should coincide with some major update of gradebook features/ clean up of the code | 19:20 |
| aelkner | that's what i'm saying | 19:20 |
| th1a | OK. | 19:20 |
| aelkner | and cando gets involved in the evolution issues as well | 19:20 |
| aelkner | as evaulations are kept in the person object | 19:21 |
| aelkner | with the activity id being a cando competency id | 19:21 |
| aelkner | so yes, it would be a major project | 19:21 |
| aelkner | involving juggling multiple plugins | 19:21 |
| aelkner | and evolution scripts | 19:21 |
| aelkner | best done in a focused manor | 19:22 |
| aelkner | while doing no oher project work | 19:22 |
| aelkner | i don't agree with the idea of "fix as you go" in the case | 19:22 |
| aelkner | this case | 19:22 |
| aelkner | it needs to be a big bite of an even bugger apple | 19:22 |
| aelkner | or the ripping off of a very large and painful band-aid to use another analogy | 19:23 |
| aelkner | all that being said | 19:24 |
| aelkner | i could still entertain the idea of using a new container for the ReportSheets | 19:24 |
| aelkner | which would give me a chance to get comfortable with the idea of moving existing data | 19:25 |
| aelkner | i'll think about the container solution | 19:25 |
| aelkner | ignas, th1a: enough of your time spent on this for now | 19:26 |
| aelkner | thanks | 19:26 |
| th1a | Let us know what you decide to do. | 19:29 |
| aelkner | will do | 19:30 |
| *** jstraw has joined #schooltool | 20:57 | |
| *** alga has quit IRC | 21:01 | |
| *** ignas has quit IRC | 21:12 | |
| *** ignas has joined #schooltool | 21:38 | |
| *** ignas has quit IRC | 21:45 | |
| *** jelkner has joined #schooltool | 21:45 | |
| *** jfroche has quit IRC | 21:53 | |
| *** lisppaste5 has quit IRC | 21:58 | |
| *** lisppaste5 has joined #schooltool | 22:04 | |
| *** jelkner has quit IRC | 22:04 | |
| *** ignas has joined #schooltool | 22:15 | |
| ignas | th1a, ayt? | 22:15 |
| th1a | I am here, ignas. | 22:30 |
| *** alga has joined #SchoolTool | 22:30 | |
| ignas | just so you know it early - Justas is very sick, and it might happen so that he does not come with me to US | 22:30 |
| ignas | he's going to see a doctor tomorrow morning | 22:30 |
| th1a | OK. | 22:30 |
| th1a | Well, I hope he feels better either way. | 22:30 |
| ignas | yeah, me too, it seems it's something real nasty :/ | 22:31 |
| th1a | What kind of nasty? | 22:32 |
| ignas | "Acute tonsillitis" i think | 22:32 |
| ignas | at least that's what wikipedia suggests | 22:32 |
| th1a | Ah. | 22:32 |
| th1a | Oh, that's the Wikipedia diagnosis? | 22:33 |
| ignas | that's the wikipedia translation | 22:33 |
| th1a | OK. | 22:35 |
| th1a | What is it in Lithuanian? | 22:35 |
| ignas | angina | 22:36 |
| th1a | Huh. That means something different in English. Heart pain. | 22:36 |
| ignas | well - it's called angina in 10 other languages too ;) | 22:37 |
| th1a | Weird. | 22:37 |
| ignas | ok 5 other languages, including french and russian | 22:38 |
| th1a | I'm sure medical etymology is a fascinating subject. | 22:39 |
| ignas | :) | 22:39 |
| ignas | as long as you are not diagnosed in english and cured in french ;) | 22:39 |
| th1a | http://www.etymonline.com/index.php?search=angina&searchmode=none | 22:40 |
| ignas | yep, it's this one | 22:41 |
| ignas | nice resource by the way | 22:41 |
| * ignas bookmarks it | 22:41 | |
| th1a | ignas: I'm having my periodic confrontation with Rosetta. | 22:58 |
| * jstraw wants to stab jelkner | 22:58 | |
| jstraw | he really needs to join the like... 20th century | 22:58 |
| jstraw | and get on IRC/IM more | 22:58 |
| ignas | are irc logs admisable in court? | 22:58 |
| th1a | Is he sending you messages by pneumatic tube again? | 22:58 |
| ignas | :D | 22:58 |
| jstraw | ignas: not really | 22:59 |
| jstraw | th1a: no... he's totally non-realtime contactable | 22:59 |
| jstraw | I can email him | 22:59 |
| jstraw | but he has no cell phone | 22:59 |
| jstraw | and doesn't get on any sort of chat client regularly | 22:59 |
| th1a | ignas: Do you think I should be making release series the "preferred" series to translate? | 22:59 |
| * jstraw thinks so | 22:59 | |
| th1a | As opposed to development, which still has, like, SchoolBell templates? | 23:00 |
| * ignas thinks he should sort out the translations mess | 23:00 | |
| ignas | maybe during the sprint | 23:00 |
| * jstraw wants to sick chris and filip on making cando translatable at some point | 23:00 | |
| th1a | Maybe I should ask for some advice on how to actually do it then, because I can't figure it out. | 23:01 |
| th1a | OK, I asked a question on Launchpad. | 23:03 |
| ignas | afk | 23:06 |
| *** jstraw has left #schooltool | 23:52 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!