| *** ignas__ has quit IRC | 01:45 | |
| *** ignas has joined #schooltool | 02:11 | |
| *** didymo has joined #schooltool | 02:15 | |
| *** didymo has quit IRC | 02:30 | |
| *** didymo has joined #schooltool | 03:07 | |
| *** didymo has quit IRC | 03:44 | |
| *** ignas has quit IRC | 05:02 | |
| *** ignas has joined #schooltool | 06:02 | |
| *** ignas has left #schooltool | 06:22 | |
| *** SteveA has joined #schooltool | 08:58 | |
| *** jinty has joined #schooltool | 12:11 | |
| *** jinty has quit IRC | 12:30 | |
| *** mgedmin has joined #schooltool | 13:12 | |
| *** ignas has joined #schooltool | 14:29 | |
| *** vidasp has joined #schooltool | 14:52 | |
| *** jinty has joined #schooltool | 14:58 | |
| *** th1a has joined #schooltool | 15:13 | |
| *** jelkner has joined #schooltool | 15:21 | |
| jelkner | srichter: good morning, stephan! | 15:26 |
|---|---|---|
| mgedmin | good afternoon, everyone | 15:26 |
| th1a | First item of business, can we move this to 1430 next week? | 15:27 |
| srichter | yes | 15:27 |
| ignas | suits me | 15:28 |
| mgedmin | +1 | 15:28 |
| * mgedmin changes the time in his pda | 15:28 | |
| jinty | afternoon, | 15:28 |
| *** mgedmin changes topic to "SchoolTool development | IRC logs at http://source.schooltool.org/irclogs/ | Buildbot: http://source.schooltool.org/buildbot/ | Dev meetings Mon, 13:30 UTC (14:30 UTC starting from December 2005)| CanDo dev meetings Tue, 4pm EST" | 15:29 | |
| th1a | If it is in mgedmin's pda, it must be official. | 15:30 |
| th1a | OK. The big news of the week was the meeting between srichter and pcardune. | 15:31 |
| th1a | I was only able to sit in with them on Monday, spewing germs all over srichter's apartment. | 15:32 |
| srichter | at least I did not get sick ;-) | 15:32 |
| th1a | But I was very impressed by how much they achieved before lunch on Monday, and I'm really happy with the code that has been checked in. | 15:32 |
| srichter | right, so Tom is talking about schooltool.requirement | 15:33 |
| th1a | I'm also excited to be working on a subject I understand really well, unlike say, calendaring ;-) | 15:33 |
| srichter | I think it turned out to be pretty good | 15:33 |
| srichter | Paul started working on porting CanDo to this new framework as well | 15:33 |
| srichter | so it will serve as a nice testbed | 15:34 |
| th1a | srichter: Can you give us a summary of the three days? | 15:34 |
| srichter | there were a lot of things that were only marginal relevant to SchoolTool | 15:35 |
| srichter | I showde Paul a lot of the new framework, demonstrating how we can insert Cando better into SchoolTool now. | 15:35 |
| th1a | In case the context isn't clear: jelkner paid for pcardune, the lead developer of CanDo, to fly up to Boston and work with srichter for three days to learn more about Zope 3 and plan out the next version of CanDo. | 15:36 |
| srichter | This included viewlets, subscribers and a lot of other relevant technologies | 15:36 |
| srichter | then we actually ported the latest CanDo trunk to the SchoolTool trunk | 15:37 |
| srichter | rearranging its SVN repository layout | 15:37 |
| srichter | CanDo is now using a buildout process to get working, instead of forking the SchoolTool trunk all the time | 15:37 |
| srichter | in the process we discovered, of course, some brittle tests in SchoolTool and fixed them | 15:38 |
| srichter | the second big task we tackled was a very generic and flexible requirements framework (the one we mentioned before) | 15:38 |
| srichter | it is located in schooltool.requirement | 15:39 |
| srichter | it is meant to fulfill all use cases for CanDo and the ST gradebook | 15:39 |
| th1a | In this case, a "requirement" is a base class for both objectives/competencies and assignments. | 15:39 |
| th1a | A requirement is essentially "something that can be assessed." | 15:40 |
| srichter | (we actually developed this in full XP style, writing tests first, which was fun, since the problem domain was so well understood -- i.e. we had a reference implementation) | 15:40 |
| srichter | right | 15:40 |
| th1a | jelkner and dwelsh did a good job briefing pcardune on the various use cases. | 15:41 |
| srichter | The interesting part about requirements are that they can be inherited | 15:41 |
| srichter | so you can say I am Yorktown Highschool and our requirements inherit all the requirements from the State of Virginia | 15:41 |
| srichter | and then I am teaching Section X, which inherits the school's requirements | 15:42 |
| srichter | we also implemented necessary annotation adapters for this | 15:43 |
| srichter | in the second part we concentrated on the assessment itself. | 15:43 |
| srichter | which included a simple pipline-like query engine for evaluations | 15:44 |
| srichter | (so that you can say: for my evaluations give me all evaluations that were made by teacher X in the year 2005 | 15:45 |
| th1a | This code will be the foundation of both the new CanDo version and the SchoolTool gradebook. | 15:45 |
| srichter | We provided two standard query methods, but also provided a base adapter class to implement other queries | 15:45 |
| srichter | yep | 15:45 |
| srichter | btw, I think we have some pretty solid documentation in the README.txt file | 15:46 |
| th1a | CanDo's independent codebase will shrink. | 15:46 |
| th1a | Ideally, it will ultimately just become a skin and we'll assimilate all the code ;-) | 15:46 |
| th1a | I found the README.txt to be very useful. | 15:47 |
| th1a | Any questions before we move on? | 15:47 |
| mgedmin | is there anything in particluar that we should know if we start writing new views? | 15:48 |
| mgedmin | (viewlets/slots/names in the standard macros/anything)? | 15:48 |
| th1a | That is the big question. | 15:48 |
| srichter | no, not at this point | 15:48 |
| th1a | No? | 15:48 |
| srichter | we only have very few viewlet managers right now | 15:48 |
| srichter | we created a new one while working with Paul | 15:49 |
| srichter | it will not be much more work for me to change the viewlets as we go | 15:49 |
| th1a | Well, we have to know how this is going to happen. | 15:49 |
| srichter | mgedmin: of course, if you find a spot where a viewlet manager would be desirable, you should either (a) send me a mail or (b) make it a viewlet manager | 15:50 |
| th1a | Don't we know where the viewlets need to go? | 15:50 |
| srichter | I want to discover those places, liek I did with Paul :-) | 15:50 |
| th1a | Doesn't bskahan's wireframe cover that? | 15:50 |
| srichter | before the second phase of the UI work is done, I will sweep accross the UI anyways to make sure the packages are separateble | 15:51 |
| th1a | Yeah, but I don't understand why we don't have the viewlets ready for upcoming development. | 15:51 |
| th1a | How are we supposed to know what to tell you we need? | 15:52 |
| srichter | ok, that's the prime questions :-) | 15:53 |
| srichter | so we always write views for content components | 15:54 |
| srichter | but sometimes we want information about another content component in our views | 15:54 |
| srichter | currently we just add some code in the view class that does the necessary lookup | 15:55 |
| srichter | and this creates an explicit or implicit dependency on that other package | 15:55 |
| srichter | instead, we should create a viewlet manager at this time and allow the other package to register a viewlet with that viewlet manager | 15:55 |
| srichter | this way our views are as componentized as the rest of the code | 15:56 |
| srichter | any questions? :-) | 15:56 |
| th1a | We don't have a viewlet manager yet? | 15:56 |
| srichter | yes, we have several | 15:57 |
| th1a | Oh, there isn't just one. | 15:57 |
| srichter | one for the main navigation (as of last week) | 15:57 |
| srichter | one for the header (which inserts the dev mode menu, when registered) | 15:57 |
| th1a | OK. So you have a manager for each point you want to use viewlets? | 15:58 |
| srichter | another one will be the notes column in components supporting IHaveNotes | 15:58 |
| srichter | yes | 15:58 |
| srichter | note that I still have to solve the issue where to place the glue code; Zope 3 in general has not solved this issue yet | 15:58 |
| srichter | for example, let's take schooltool.note | 15:59 |
| srichter | st.note defines an interface called IHaveNotes | 15:59 |
| srichter | any object that implements this interface can have notes | 15:59 |
| srichter | we attach this interface usually in the class directive | 16:00 |
| srichter | now, where should that directive go? | 16:00 |
| srichter | if I add it to the st.note package, I create a depdence on st.person (for example) | 16:01 |
| th1a | mgedmin, are you following this? | 16:01 |
| mgedmin | barely ;) | 16:01 |
| srichter | if I add this directive to st.person, I create a dependence of st.note on st.person | 16:01 |
| mgedmin | we just got some food delivered to the office | 16:01 |
| srichter | I think the answer will be that we want a glue package :-) | 16:01 |
| th1a | Well, I don't know that we have to worry about making all these packages absolutely indpendent of each other. | 16:02 |
| mgedmin | ok, I'm following this now | 16:02 |
| th1a | I'd just put it in schooltool.notes. | 16:02 |
| srichter | I think that this glue package is schooltool.app, but st.person and st.note already depend on schooltool.app :-( | 16:02 |
| mgedmin | srichter, what about conditional dependencies? | 16:03 |
| srichter | th1a: so you are saying that schooltool.note will depend on schooltool.person and schooltool.group? | 16:03 |
| mgedmin | the zcml:have-feature thingies? | 16:03 |
| srichter | mgedmin: right, so that would make it a soft (or implicit) dependency | 16:03 |
| srichter | but it is still a dependency :-) | 16:03 |
| th1a | It just means that if you want to use schooltool.note elsewhere you need to change some zcml? | 16:03 |
| srichter | th1a: right | 16:03 |
| mgedmin | <class zcml:if-have-feature="schooltool.notes" ".Person"><implements interface="st.notes.IHaveNotes" /></class> or whatever the syntax is | 16:03 |
| srichter | yes, this is possible | 16:04 |
| srichter | I am just not sure whether it is the right solution | 16:04 |
| th1a | We're not striving for perfection here. | 16:04 |
| mgedmin | I agree that it is not ideal, but it is better than a hard dependency | 16:04 |
| srichter | absolutely | 16:04 |
| th1a | Drop dead simple re-use of individual components outside of SchoolTool isn't a high priority. | 16:04 |
| srichter | but I would rather get a generally agreed way of doing this in the Zope 3 community | 16:05 |
| srichter | luckily the issue does not have to be solved at this point | 16:05 |
| mgedmin | maybe we should get back to the agenda of the meeting | 16:05 |
| th1a | We don't need to solve it. | 16:05 |
| th1a | Well, I'm still a little murky about viewlets. | 16:05 |
| srichter | well, I am also thinking about different SchoolTool releases | 16:06 |
| th1a | They'll all have schooltool.person and schooltool.group, right? | 16:06 |
| srichter | th1a: I suggest reading the README.txt file in zope.viewlet (it has motivation in it too) and zope.contentprovider (that one first) | 16:06 |
| srichter | th1a: then look at some implementations in SchoolTool; I think the devmode one is really simple | 16:06 |
| srichter | th1a: right | 16:07 |
| th1a | I mean, I'm still murky about where the viewlet managers are in SchoolTool. | 16:07 |
| srichter | but note that this was just an example | 16:07 |
| th1a | I'd like the standard viewlet managers to be done. | 16:07 |
| srichter | th1a: ahh, ok; they are now in schooltool.app.browser.skin | 16:07 |
| th1a | And if we can't find one we're expecting in there we should poke you? | 16:08 |
| srichter | yes | 16:09 |
| srichter | I'll consider that part of that contract :-) | 16:10 |
| srichter | if you have questions, bug me | 16:10 |
| th1a | OK... | 16:10 |
| th1a | I shall. | 16:10 |
| srichter | I try to stay very responsive to those requests | 16:10 |
| th1a | OK. Moving on then. | 16:10 |
| th1a | POV. What's your schedule? We haven't finalized the next contract. Is alga windsurfing? | 16:11 |
| mgedmin | alga is having a vacation somewhere far far away | 16:12 |
| th1a | Yes, he told me he was going. | 16:12 |
| mgedmin | we plan to start working on SchoolTool today | 16:12 |
| th1a | Do you have time estimates? | 16:13 |
| mgedmin | there are come questions about some of the stories | 16:13 |
| mgedmin | we have some estimates | 16:13 |
| mgedmin | they're confusing | 16:14 |
| th1a | The estimates or the stories? | 16:14 |
| mgedmin | approximatelly 30-40 days of work | 16:14 |
| mgedmin | the estimates ;) | 16:14 |
| mgedmin | there are two stories that we've already done, but haven't been paid yet | 16:14 |
| mgedmin | I'm not sure if that time is included in the total estimate at the top or not | 16:15 |
| mgedmin | anyway, the plan is to get some clarifications from you | 16:15 |
| mgedmin | and mail you the fixed proposal today | 16:15 |
| th1a | I suppose they would be. I'm mainly worried about the deadline. | 16:15 |
| th1a | OK. | 16:15 |
| mgedmin | what's the deadline? | 16:15 |
| th1a | I mean, when you will be done, which will hopefully be before Christmas. | 16:16 |
| mgedmin | I am not confident that we can implement all of the stories before Christmas | 16:17 |
| * mgedmin is often very pessimistic | 16:17 | |
| th1a | OK. I'll take a look at your proposal when you send it. | 16:17 |
| mgedmin | questions about the homeroom period story: | 16:18 |
| th1a | But you're otherwise ready to start work? | 16:18 |
| mgedmin | - how is the homeroom special? is it highlighted in the user interface in any way? | 16:18 |
| mgedmin | - are users allowed to schedule activities in the homeroom period? | 16:18 |
| th1a | I guess you don't have homeroom in Lithuania? | 16:19 |
| th1a | Homeroom is a special period where you essentially check in for the day. | 16:20 |
| th1a | You could schedule activities for homeroom. | 16:20 |
| th1a | And it will generally be designated simply by name, if it is important. | 16:20 |
| th1a | i.e., when you set up your schema: 'homeroom,' 'period 1,' period 2' etc. | 16:21 |
| th1a | But in some cases, a regular period also counts as homeroom. | 16:21 |
| mgedmin | so, the answers to my questions are 'no' and 'no'? | 16:22 |
| th1a | So it is just 'period 1,' which is regular academic class, but that teacher is also responsible for doing the "day" attendance and sending it to the office. | 16:22 |
| th1a | 'No' and 'yes.' | 16:22 |
| th1a | No, no, yes. | 16:22 |
| th1a | SOrry. | 16:22 |
| mgedmin | oops, yes | 16:22 |
| mgedmin | in other words the system and the user do not care that 'period 1' on Tuesday is a homeroom period? | 16:23 |
| mgedmin | if that is the case, I do not see the point on marking it as a homeroom period when you create the timetable | 16:23 |
| th1a | The system needs to know which period is homeroom, because the attendance info for that period is used to determine the student's attendance status for the whole day. | 16:24 |
| mgedmin | ah! | 16:24 |
| th1a | I assume that Lithuanian schools handle attendance more like US colleges. | 16:25 |
| th1a | You are only absent per class. | 16:25 |
| ignas | yep | 16:25 |
| mgedmin | yes | 16:25 |
| th1a | There is no sense of missing a day. | 16:26 |
| ignas | btw - what about permissions for the homeroom form ? | 16:26 |
| ignas | we don't have clercs/admins yet | 16:26 |
| ignas | so it would appear in the already long list of all permissions | 16:26 |
| th1a | Didn't I put that in your stories? | 16:26 |
| mgedmin | you mean "default groups"? | 16:27 |
| th1a | Yes. | 16:27 |
| mgedmin | I'm out of questions for now | 16:28 |
| mgedmin | (I'm sure some new ones will appear when we actually start working) | 16:28 |
| mgedmin | ah, one more | 16:28 |
| mgedmin | the basic wfmc model for attendance | 16:28 |
| mgedmin | will you supply us with an XML file describing the workflow? | 16:28 |
| mgedmin | or should we try to write one? | 16:28 |
| th1a | I should probably get srichter to help me make one for you. | 16:29 |
| th1a | And we'll show you how to edit it. | 16:29 |
| th1a | One more thing for context... | 16:30 |
| th1a | In US primary and secondary schools, skipping a class during the day is a pretty big deal. | 16:30 |
| th1a | It is like, once you've checked in at homeroom, they expect to know where you are every minute until the end of the day. | 16:31 |
| th1a | In public schools, that is. | 16:31 |
| mgedmin | RFID implants? | 16:31 |
| th1a | Coming soon. | 16:31 |
| srichter | I think JaWE is the way to go for those XML files | 16:31 |
| th1a | srichter: Right. | 16:33 |
| th1a | I guess I'll take a crack at it. | 16:33 |
| th1a | On the other hand, I had some trouble getting JaWE to run on Breezy, so that might be a problem. | 16:33 |
| th1a | Anyhow, time's up. | 16:34 |
| * th1a hits the virtual gavel. | 16:34 | |
| *** th1a has quit IRC | 16:41 | |
| *** th1a has joined #schooltool | 16:47 | |
| *** jelkner has quit IRC | 17:06 | |
| mgedmin | th1a, question about absences in the student's calendar | 17:58 |
| mgedmin | are they only visible when you go to /persons/$student/calendar | 17:58 |
| mgedmin | or do you want to also see them if you include a student's calendar in your overlay? | 17:58 |
| th1a | This is just a convenience. | 17:59 |
| * mgedmin hopes the first one is desired | 17:59 | |
| th1a | Isn't the second one harder? | 17:59 |
| mgedmin | yes | 17:59 |
| th1a | I mean, wouldn't it be easiest to just make them act like regular calendar events? | 18:00 |
| th1a | Regardless, this may end up being cut... it isn't a big deal. | 18:00 |
| mgedmin | they will be regular calendar events | 18:00 |
| mgedmin | regular read-only calendar events | 18:01 |
| th1a | On the student's calendar? | 18:01 |
| mgedmin | coming from a dynamically-computed read-only calendar | 18:01 |
| mgedmin | so it is just a matter for splicing it into the list of calendars-to-be-overlaid in the view | 18:01 |
| th1a | OK. That sounds fine. | 18:01 |
| newnick | srichter, is the README.txt for zope.viewlets in Zope3 tree? | 18:21 |
| newnick | I can't seem to find it. | 18:21 |
| srichter | newnick: yes | 18:33 |
| srichter | zope.viewlet/README.txt | 18:33 |
| Aiste | hi th1a | 18:46 |
| Aiste | got a moment? | 18:46 |
| th1a | Yes. | 18:53 |
| th1a | hi Aiste. | 18:53 |
| Aiste | we have worked out the proposal finally | 18:54 |
| th1a | OK. | 18:54 |
| Aiste | the numbers of it are ass follows -- estimated time -- 45 programmer days | 18:55 |
| Aiste | real time date we can finish all of the stories -- end of January | 18:55 |
| th1a | OK. | 18:56 |
| Aiste | as simple as that? | 18:56 |
| Aiste | um... | 18:56 |
| * Aiste expected some fighting | 18:56 | |
| th1a | Well, I'll have to take a look and decide if I want to cut some. | 18:56 |
| Aiste | ok, that's what we figured | 18:56 |
| th1a | ARRRGGGH! THIS IS COMPLETELY UNACCEPTABLE. | 18:57 |
| Aiste | we'll send it to you today | 18:57 |
| th1a | Is that better? | 18:57 |
| Aiste | um... no :) | 18:57 |
| * Aiste is reading to much fantasy/medieval knights stuff :) | 18:57 | |
| th1a | I'll just also need to know soon how much time we'll have through June from POV through June. | 18:58 |
| Aiste | I should know that soon | 18:59 |
| th1a | OK. | 18:59 |
| mgedmin | th1a, the proposal is in the mail | 19:16 |
| th1a | OK. Thanks. | 19:16 |
| mgedmin | th1a, speaking about starting work | 19:21 |
| mgedmin | are there any stories you're absolutely certain you won't cut out? | 19:22 |
| th1a | We'll need those default groups. | 19:22 |
| mgedmin | (so we can start working on them now) | 19:22 |
| th1a | Actually, nothing would will be cut, but I'd like to sequence this so that we can have a milestone tarball probably between Christmas and New Year's. | 19:26 |
| th1a | So it is just a matter of being at a usable point then. | 19:27 |
| povbot | /svn/commits: * mg committed revision 5345: | 19:59 |
| povbot | /svn/commits: Fixed a couple of typos I noticed while reading the README. | 19:59 |
| povbot | /svn/commits: * ignas committed revision 5346: | 20:19 |
| povbot | /svn/commits: Fixed outdated docstring (see rev 5110 for background). | 20:19 |
| *** vidasp has quit IRC | 20:36 | |
| povbot | /svn/commits: * ignas committed revision 5347: | 20:40 |
| povbot | /svn/commits: Killed some blank lines. | 20:40 |
| povbot | /svn/commits: * ignas committed revision 5348: | 20:41 |
| povbot | /svn/commits: Added missing unit test and a docstring. | 20:41 |
| ignas | th1a, ping | 20:47 |
| th1a | ignas, pong. | 20:48 |
| ignas | in default groups we already have a group that is called "Manager" | 20:48 |
| ignas | the story suggests adding Site Manages group | 20:48 |
| ignas | s/Manages/Managers/ | 20:48 |
| th1a | Oh yes. | 20:48 |
| ignas | two managers groups might be confusing | 20:48 |
| ignas | can we rename the existing group so Site Managers ? | 20:49 |
| th1a | Well, I meant the existing "manager." | 20:49 |
| ignas | good, thanks | 20:49 |
| th1a | NP. | 20:49 |
| ignas | could you please come up with sensible descriptions for these groups ? | 20:52 |
| povbot | /svn/commits: * mg committed revision 5349: | 22:16 |
| povbot | /svn/commits: Made the ACL restive view pretty and not brittle. | 22:16 |
| povbot | /svn/commits: * ignas committed revision 5350: | 22:18 |
| povbot | /svn/commits: Added a number of default groups. | 22:18 |
| *** mgedmin has quit IRC | 22:22 | |
| povbot | /svn/commits: * ignas committed revision 5351: | 22:26 |
| povbot | /svn/commits: Documented a non-trivial corner case in the functional test. | 22:26 |
| *** ignas has quit IRC | 22:30 | |
| *** jinty has quit IRC | 23:40 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!