**** BEGIN LOGGING AT Mon Jul 26 13:28:10 2004 | ||
-->You are now talking on #schooltool | 13:28 | |
---Topic for #schooltool is www.schooltool.org || IRC logs at http://stone.tuttlesvc.org:880/logbot/ | 13:28 | |
---Topic for #schooltool set by mgedmin at Fri Jul 16 18:15:52 2004 | 13:28 | |
-TomLogging-This channel is logged - http://stone.tuttlesvc.org:880/logbot/ | 13:28 | |
alga | thisfred: hi | 15:57 |
---|---|---|
-->th1a (~hoffman@pool-64-222-39-13.prov.east.verizon.net) has joined #schooltool | 15:57 | |
alga | may I ask, why are you interested in Schooltool? | 15:57 |
th1a | Are you asking me? | 15:57 |
alga | thisfred | 15:58 |
alga | hi, Tom | 15:58 |
th1a | Good morning, alga. | 15:58 |
-->gintas (~gintas@office.pov.lt) has joined #schooltool | 15:58 | |
*th1a goes to feed his fish. | 16:01 | |
alga | nicccce fishessss | 16:02 |
th1a | So juicy sweet! | 16:02 |
th1a | Not really. They're koi. | 16:03 |
th1a | OK, shall we begin? | 16:03 |
mgedmin | ok | 16:03 |
alga | OK | 16:04 |
th1a | I added some little '+' marks to indicate more fine grained priorities on the wiki page. | 16:04 |
alga | uhuh, I noticed | 16:05 |
alga | OK. | 16:05 |
alga | HTML Interface | 16:05 |
alga | what do we need to be able to do through it? | 16:05 |
th1a | You should be able to use the whole system without using an external client at all. | 16:06 |
alga | All the current functionality of schooltool? | 16:07 |
alga | And moz cal does not count? | 16:07 |
th1a | This is the calendaring release. | 16:07 |
alga | I mean, we should not rely on moz cal as the client for the hard parts? :) | 16:07 |
th1a | Yeah. I don't want Moz Cal to be a requirement for using this product. | 16:08 |
alga | so, add, remove, modify people and groups | 16:08 |
alga | view, edit their calendars | 16:09 |
alga | set up relationships | 16:09 |
th1a | Yeah. | 16:09 |
alga | that would be a good starting point, right? | 16:10 |
th1a | Yes. | 16:10 |
th1a | I don't know how much interest you guys have in web design. | 16:11 |
th1a | It is not out of the question that some of the web design part could be done by someone else. | 16:11 |
alga | hm, I think, we will/can produce some clean minimalistic design, but nothing fancy. | 16:12 |
alga | see pov.lt -- that kind of thing | 16:13 |
th1a | That's fine, | 16:13 |
th1a | If it gets fancied up eventually we should be able to do that mostly with CSS. | 16:13 |
alga | OK, making a web interface for groups, people, etc is about 1 man week | 16:14 |
alga | calendaring is a separate issue | 16:14 |
alga | do you have a vision/example how you want the calendars to look/feel? | 16:15 |
thisfred | alga: hi, sorry ;) | 16:15 |
th1a | OK. | 16:15 |
-->sabdf1 (~mark@host217-37-231-28.in-addr.btopenworld.com) has joined #schooltool | 16:15 | |
th1a | Quite frankly I don't have any strong feelings about it. | 16:15 |
sabdf1 | hi all, mark s here | 16:15 |
th1a | Hi Mark. | 16:16 |
alga | hi mark | 16:16 |
mgedmin | hi Mark | 16:16 |
thisfred | hi mark | 16:16 |
gintas | hi Mark | 16:16 |
alga | :) | 16:16 |
alga | I imagine our first iteration of the calendar web UI will be quite lame | 16:16 |
th1a | I'll have to look at existing implementations of HTML calendars. | 16:16 |
th1a | It isn't something I use. | 16:17 |
alga | but we will be able to use it as a basis for improvement | 16:17 |
th1a | Currently. | 16:17 |
th1a | I'd just like it to be clean and valid to start. | 16:18 |
alga | hm, I think a simple cal view with a table of one month, links next month, prev month, and being able to click on a day and edit (add, remove, modify) the events in that day | 16:20 |
th1a | Probably a weekly view, too. | 16:21 |
alga | would be something like 4 dev days | 16:21 |
alga | the 4-day version would probably have rough edges | 16:22 |
alga | but then we might go and improve it | 16:22 |
alga | what do you think? | 16:22 |
sabdf1 | yahoo claender has a great ui for display of week/day/month views | 16:23 |
sabdf1 | s/claender/calendar/ | 16:23 |
alga | ok, we'll take a look at that | 16:23 |
*th1a wonders if we should have someone else work on the visual design. | 16:23 | |
alga | maybe, but anyway we have to have functionaliity done in HTML first | 16:24 |
th1a | Right. | 16:24 |
alga | so -- what do you think? Story 1 -- groups, persons rels in HTML -- 1 week | 16:25 |
alga | Story 2 -- simple calendar view -- 4 days | 16:25 |
th1a | Sounds reasonable to me. | 16:26 |
mgedmin | I'm trying to write down a more detailed list of UI bits that need to be done | 16:28 |
th1a | OK. | 16:28 |
mgedmin | * login page (username/password, "login failed" message) | 16:29 |
mgedmin | * a user's home page (basic user's info, what groups she belongs to, a list of allowed actions, links to default calendar views) | 16:29 |
mgedmin | A manager's home page will contain buttons for actions (e.g. new user, new group) | 16:29 |
mgedmin | * page for editing an existing user's info (name, etc.) | 16:30 |
mgedmin | * page for creating a new user (mostly the same as above) | 16:30 |
mgedmin | * page for creating a new group | 16:30 |
mgedmin | * page for editing group's info | 16:31 |
mgedmin | (actually I'm not sure if groups have anything worth editing, perhaps the last one isn't necessary) | 16:31 |
mgedmin | * group's home page (list of parent groups, list of members, etc.) | 16:31 |
mgedmin | no, it should be just "group's page" -- home page is something a user gets when he logs in, and groups cannot log in | 16:32 |
mgedmin | * pages for establishing/removing relationships | 16:32 |
mgedmin | * three calendar views (monthly, weekly, daily) | 16:32 |
mgedmin | * page for adding/editing a calendar event | 16:33 |
alga | what about timetable models, schoolday calendars and all that stuff? | 16:34 |
alga | will we leave in in XML only for the time being, or a HTML interface is required too? | 16:34 |
mgedmin | good question | 16:34 |
alga | and timetables! | 16:35 |
th1a | It might not be a bad idea to leave that to the client interface. | 16:35 |
mgedmin | what do we from need timetabling for the calendaring release? | 16:35 |
th1a | Viewing a timetable is the same as a calendar right? | 16:35 |
mgedmin | what do you mean by "client interface"? The GUI client? | 16:35 |
th1a | Yeah. wx. | 16:35 |
alga | so, the admins will have to use specialized clients, but students, parents, teachers won't? | 16:36 |
mgedmin | viewing a timetable might be different from viewing a calendar | 16:36 |
mgedmin | but viewing a calendar derived from a timetable is the same | 16:37 |
alga | but we have an HTML view for timetables already! | 16:37 |
mgedmin | true | 16:37 |
th1a | Let's look at it this way. I wouldn't mind requiring the administrator of the system to use the wx client. | 16:38 |
th1a | But I'd like users to be able to do everything via the web. | 16:38 |
mgedmin | so stories like 'add a user', 'add a group' are less important | 16:38 |
th1a | By that approach we could cut down on the amount of web work to be done now. | 16:38 |
mgedmin | because only admins can create users and groups | 16:38 |
th1a | Perhaps. It seems like a reasonable approach. | 16:39 |
alga | th1a: what is the aim of this meeting? what do you want done by the end of it? | 16:39 |
alga | are we just clarifying stories? | 16:39 |
th1a | At minimum. I think there is some clarifying to be done. | 16:40 |
mgedmin | yes | 16:40 |
th1a | We probably should do a clarifying pass before we calculate times, etc. in detail. | 16:40 |
mgedmin | th1a: how about adding my list of "UI bits" to the list of stories on the wiki? | 16:41 |
mgedmin | (http://www.schooltool.org/bounties/SchoolBellStories) | 16:41 |
th1a | OK. | 16:41 |
th1a | The second big area is delegation. | 16:42 |
*mgedmin is editing the page | 16:42 | |
th1a | mgedmin: are you adding your list? Someone has the wiki locked. | 16:43 |
mgedmin | yes | 16:44 |
th1a | OK. | 16:44 |
th1a | Thanks. | 16:45 |
mgedmin | it seems that I'm unable to save my changes: the page is locked | 16:48 |
th1a | Anyone using external editor on the wiki page? | 16:49 |
mgedmin | I am | 16:49 |
th1a | Oh. | 16:49 |
th1a | So that shouldn't be happening. | 16:49 |
th1a | I think I can break the lock. | 16:50 |
th1a | mgedmin: just save your version locally. let's move on and I'll figure out how to break the lock later. | 16:52 |
th1a | So delegation... | 16:53 |
th1a | Will require a fair amount of work on the security infrastructure of SchoolTool, I imagine. | 16:53 |
mgedmin | perhaps not | 16:55 |
mgedmin | there will be a fair amount of work for managing the ACLs, though | 16:57 |
mgedmin | could you clarify "A person should be able to delegate other people to manage their own events."? | 16:58 |
th1a | Questions about how this should work? | 16:58 |
mgedmin | did you mean that a person should be able to delegate other people to manage his (or her) events? | 16:59 |
th1a | So the principal can allow his secretary to add and edit his calendar. | 16:59 |
th1a | mgedmin: yes | 16:59 |
mgedmin | "their" confused me | 16:59 |
th1a | My English is perhaps not as proper as yours. | 16:59 |
alga | it seems that once we get | 17:00 |
mgedmin | I'm reading "BUGS in Writing" now ;) | 17:00 |
mgedmin | how granular is the delegation? | 17:00 |
alga | it seems that once we get ACL's to work most of those stories will be very easy? | 17:00 |
th1a | It doesn't seem like one is particularly harder than the others. | 17:01 |
th1a | Well, editing and deleting should probably be different than adding. | 17:02 |
th1a | For resource scheduling you really don't want teachers erasing each other's reservations. | 17:02 |
th1a | But you'd like them to be able to add themselves. | 17:02 |
alga | CRUD! | 17:03 |
mgedmin | ? | 17:03 |
alga | create remove? update delete | 17:03 |
alga | create retrieve update delete | 17:03 |
alga | four kinds of actions to define in an ACL | 17:03 |
th1a | BTW. Creating a reservation/event for a resource should probably only be allowed via the web. | 17:04 |
th1a | Because we'll need to handle conflicts. | 17:04 |
th1a | And I don't think we'll be doing conflicts from ICal interaction. | 17:05 |
mgedmin | yes | 17:05 |
mgedmin | I think that currently resource calendars (iCal) are read-only for that reason | 17:06 |
th1a | Is it even possible to handle conflicts from ICal -- is there a "sorry, there's a conflict" error code? | 17:06 |
mgedmin | ICal itself is not a protocol for updating calendars | 17:06 |
th1a | Right. | 17:07 |
mgedmin | AFAIU ICal has no special provisions for representing conflicts | 17:07 |
mgedmin | we could simply reject the full update | 17:07 |
mgedmin | and return an HTTP error code | 17:07 |
mgedmin | but I do not know how Mozilla Calendar would handle that | 17:08 |
th1a | Yeah. | 17:08 |
th1a | Let's assume that resource scheduling is via web only. | 17:08 |
th1a | If people double-book their personal schedule, that's their own problem. | 17:08 |
th1a | Anything more to say about delegation? | 17:09 |
mgedmin | "A manager should be able to delegate the manager role for a group or resource." | 17:10 |
mgedmin | could you elaborate on that | 17:10 |
mgedmin | ? | 17:11 |
alga | I think I get it | 17:11 |
*alga explains to mgedmin via air | 17:11 | |
mgedmin | can the delegatee delegate the manager role to a third person? | 17:11 |
th1a | Good question. I don't see why not, but in the long-term I guess it might be bad for security overall. | 17:13 |
alga | the security is tighter if only managers can set up delegations | 17:13 |
th1a | I'd think. | 17:13 |
alga | only real managers, I mean | 17:13 |
th1a | That seems reasonable. | 17:13 |
alga | so, the delegation would just grant a user all create and update rights on a group | 17:14 |
th1a | And they can add or remove members from the group. | 17:14 |
alga | that's updating a group | 17:15 |
th1a | OK. | 17:15 |
alga | it's creating relationships on a group in fact | 17:15 |
th1a | Indeed. | 17:15 |
alga | I think we can move on | 17:16 |
alga | things are pretty clear here on the requirements level | 17:16 |
th1a | Cool. | 17:17 |
alga | will the freebusy calendars be public on all objects? | 17:18 |
th1a | Can anyone think of a compelling reason why they shouldn't? | 17:18 |
alga | privacy? | 17:18 |
alga | it seems that you know most about the privacy concerns though | 17:19 |
alga | > When sceduling a resource, the system should by default assume that you want to book the resource for a block of time corresponding to the main timetable for the school, e.g., teacher's will be thinking, "I need the computer lab first period", not 9:03 - 9:51. | 17:20 |
th1a | Do you need some clarification? | 17:20 |
alga | Maybe all calendars should be available with hours:mins or periods?? | 17:20 |
alga | some UI switch? | 17:20 |
th1a | Yeah, I guess that does apply to events in general. Meetings, etc. | 17:21 |
th1a | So yes, a UI switch of some sort. | 17:21 |
alga | hm, schooltool supports different timetable schemas at the same time | 17:22 |
th1a | mgedmin: for whatever reason, the DAV lock on the wiki seems to be gone. | 17:22 |
mgedmin | I'm not using external editor now | 17:23 |
th1a | Hm. Odd. | 17:23 |
mgedmin | I (thought that I) saved my local changes, closed the editor | 17:24 |
mgedmin | clicked on the external edit icon again | 17:24 |
mgedmin | tried saving the page without any changes | 17:24 |
mgedmin | it worked | 17:24 |
mgedmin | tried saving the page without any changes again | 17:24 |
mgedmin | it didn't | 17:24 |
mgedmin | I gave up | 17:24 |
th1a | Good choice. | 17:24 |
mgedmin | the only problem is that the file where I thought I saved my changes does not exist | 17:24 |
th1a | Oy. | 17:24 |
th1a | From a development point of view, "Delegation" and "Access Control" are essentially the same thing, right? | 17:27 |
th1a | All CRUD. | 17:28 |
mgedmin | yes | 17:28 |
mgedmin | the stories look very similar | 17:28 |
mgedmin | "Each person can designate which group calendars will appear as part of their free/busy schedule when requested by another person." | 17:29 |
mgedmin | what happens to group calendars that are not designated? | 17:29 |
mgedmin | they do not influence the free/busy schedule at all? | 17:29 |
th1a | Yeah. | 17:29 |
th1a | If I am the basketball coach, I'm busy every time there is a basketball game. | 17:30 |
alga | and membership+teaching are not good enough designators? | 17:30 |
th1a | But I also want to see the general school event calendar, but I only attent a fraction of school wide events. | 17:30 |
th1a | I go to all the basketball events if I am a basketball player, too. | 17:30 |
alga | so, in general you'd want all the groups you belong to, plus some others? | 17:31 |
mgedmin | I assumed that "group calendars" referred to calendars of groups that the person belongs to | 17:31 |
alga | Btw, basketball players belong to a Basketball group that the coach 'teaches' | 17:31 |
th1a | mgedmin: right. | 17:32 |
th1a | All the teachers, for example, will often subscribe to the "teachers" calendar. | 17:33 |
th1a | But they won't be going to all those meetings necessarily. | 17:33 |
th1a | When you are viewing a group calendar you should probably be able to check off if you'd like to add it to your calendar. | 17:34 |
alga | th1a, could you elaborate on | 17:34 |
alga | Conflict Resolution | 17:34 |
alga | Punt. | 17:34 |
alga | ? | 17:34 |
th1a | I guess you guys don't play American football? | 17:34 |
alga | :) | 17:34 |
mgedmin | my, are you clairvoyant? | 17:35 |
mgedmin | ;) | 17:35 |
th1a | Punt means "give up," "kick it to the other team." | 17:35 |
th1a | Not that there is another team... | 17:35 |
alga | ok, thanks | 17:35 |
th1a | What do you think about hooks for running scripts pre/post event creation. | 17:37 |
th1a | ? | 17:37 |
mgedmin | tricky | 17:38 |
mgedmin | especially security-wise | 17:38 |
th1a | I'd like to have a clear way for external developers to add functionality around event creation. | 17:40 |
alga | if the scripts are on the FS, in a form of "plugins", o extensions, or whatnot, the security is not so dire | 17:40 |
mgedmin | oh, right | 17:40 |
mgedmin | we have a notification model in SchoolTool | 17:40 |
th1a | Oh. That's good to know. Does it do anything now? | 17:41 |
mgedmin | it has 'events' that are completely unrelated to calendar events | 17:41 |
mgedmin | currently it sends notifications, e.g. when a relationship is created | 17:41 |
mgedmin | it would be easy to send notifications when calendar events are created | 17:42 |
th1a | Sends notification to whom? | 17:42 |
gintas | it's low-level stuff | 17:42 |
gintas | notifications are sent to subscribers | 17:42 |
mgedmin | it's highly configurable in the code | 17:42 |
th1a | Are subscribers other objects? | 17:43 |
mgedmin | doc/events.rst in svn contains a description of this subsystem | 17:43 |
gintas | callables I think | 17:43 |
mgedmin | steve advocated switching to zope 3 event implementation | 17:44 |
mgedmin | which is somewhat simpler | 17:44 |
th1a | Would that change the interfaces, or is it a straightforward refactoring? | 17:45 |
mgedmin | it probably would | 17:45 |
mgedmin | but it should be straighforward enough | 17:45 |
mgedmin | our current event system is not used for much | 17:46 |
mgedmin | absence tracking mostly | 17:46 |
th1a | Does ICal support locations for events? | 17:48 |
mgedmin | Property Name: LOCATION | 17:49 |
mgedmin | Purpose: The property defines the intended venue for the activity | 17:49 |
mgedmin | defined by a calendar component. | 17:49 |
mgedmin | Value Type: TEXT | 17:49 |
mgedmin | in other words, it does | 17:49 |
th1a | Thanks. Our events should definitely have locations. | 17:49 |
alga | I thought location is something like URI... :-) | 17:49 |
th1a | No. Where in meatspace. | 17:50 |
mgedmin | that was my first though as well, but eventually I understood ;) | 17:50 |
th1a | Actually, the location will usually, but not always, itself be a resource. | 17:50 |
th1a | If rooms in the school are resources. | 17:50 |
mgedmin | yes | 17:51 |
th1a | I'm feeling like resources need description properties soon. | 17:51 |
mgedmin | btw our calendar events now have a property (owner) that refers to a person who created the event | 17:52 |
mgedmin | so "(+)Perhaps an event should have a property containing the name of the person who made the event." is already done | 17:52 |
th1a | OK. Scratch that one. | 17:52 |
alga | are we coming to the end of the meeting? | 17:53 |
th1a | Feels like it. | 17:53 |
th1a | Can you guys work up time estimates among yourselves? | 17:54 |
alga | th1a: what do you think if now we will come up with a proposal and send it to you and SteveA in a couple of days? | 17:54 |
th1a | Sounds fine. | 17:54 |
alga | I think we can | 17:54 |
alga | I suppose you want everything done ASAP? | 17:55 |
th1a | Yes. | 17:59 |
alga | OK, thanks for the meeting | 17:59 |
th1a | Thank you! | 17:59 |
mgedmin | thank you | 18:00 |
alga | th1a: what about an m6 release? | 18:18 |
alga | should we announce it? | 18:18 |
th1a | Sure. And announce the new website is live. | 18:20 |
<--gintas has quit ("Bye") | 18:37 | |
-lilo-[Global Notice] Hi all. As you may be aware, O'Reilly's OSCON 2004 conference is in progress this week. If you're attending, or if you're just interested in knowing what's going on, please stop by freenode's unofficial #oscon channel. Thanks! | 19:21 | |
*alga just announced m6 | 19:37 | |
-->stockholm (~andreas@petrus.schuldei.org) has joined #schooltool | 19:41 | |
stockholm | hi! | 19:41 |
stockholm | th1a: i read your mail on the debian-edu list | 19:42 |
stockholm | th1a: do you have a url for the timetable generation requirements? | 19:43 |
stockholm | th1a: i am a debian-edu developer | 19:43 |
th1a | Oh hello. | 19:54 |
th1a | stockholm: I don't have a url for timetable generation requirements yet. | 19:55 |
th1a | I should put up a wiki page. | 19:55 |
stockholm | i was the one answering the mail claiming that i met the schooltood developer in brazil at debconf. (c: | 19:56 |
stockholm | actually i thought timetable generation was working allready | 19:57 |
sabdf1 | hi guys, site is looking great, thanks tom! | 19:58 |
sabdf1 | do plane and zwiki work well together? | 19:58 |
th1a | Plone and Zwiki do. | 19:58 |
sabdf1 | how about a wiki? | 19:58 |
th1a | sabdfl: for timetable requirements? | 19:59 |
th1a | stockholm: you can make timetables now but the interface isn't sophisicated enough to do it on a large scale. | 20:00 |
stockholm | ok | 20:01 |
th1a | At our school this year I'm planning on doing it on paper/in excel and importing it into SchoolTool. | 20:01 |
th1a | OK, we can start collecting requirements here: http://schooltool.org/bounties/TimeTabling | 20:14 |
stockholm | neet! | 20:22 |
stockholm | th1a: will you add that to that thread or should i? | 20:22 |
th1a | stockholm: go ahead and add what you'd like. | 20:24 |
th1a | if you aren't sure where to put something just throw it in somewhere and I'll merge it together later. | 20:25 |
stockholm | th1a: the thread on the debian-edu list. i expect the teachers to come and add feature requests. | 20:25 |
*stockholm id just a developer. (c: | 20:25 | |
th1a | Go ahead and add something yourself if you'd like. | 20:27 |
stockholm | (c: | 20:27 |
stockholm | i would wish for interfaces to the software we use to keep track of users, groups and rooms. (c: | 20:28 |
th1a | I don't want it to look like I'm the only person interested in this project! | 20:28 |
stockholm | th1a: (c: | 20:28 |
stockholm | i dont think you are, we are too | 20:28 |
th1a | Good ;-) | 20:31 |
alga | th1a: do we need anti-events? | 21:02 |
alga | stuff that makes just a single event from a timetable disappear? | 21:03 |
alga | I mean, a single occurence of a weekly event ant suchlike | 21:03 |
alga | the story sais: A manager needs to be able to edit and cancel individual events in the timetable. | 21:04 |
alga | or just nuking the whole recurrent event from the timetable is sufficient? | 21:05 |
th1a | Now that you mention it, there are lots of cases that we probably haven't touched on. | 21:05 |
th1a | One frequent one is adjusting the schedule when there is an event | 21:05 |
th1a | For example, there is a pep rally (do you have those in Europe?) at the end of the day, | 21:06 |
th1a | so all the other periods are shortened or one is eliminated to allow time for the special event. | 21:06 |
th1a | That's also a case that generally confuses everyone in the school, | 21:07 |
th1a | so it would be one time that everyone would really like to know where they can find | 21:08 |
th1a | an accurate representation of the schedule. | 21:08 |
alga | a tough one | 21:08 |
th1a | It is. | 21:09 |
alga | it might be quite hard on admins, but if they're willing to take pains, we can find several solutions | 21:09 |
th1a | Give it some thought. | 21:09 |
thisfred | My thinking would be that recurring events are *all* single events that can be cancelled individually, but they are also members of a group that can be edited as a whole. | 21:10 |
thisfred | but that may create storage overhead | 21:10 |
th1a | Yeah. That's not the way it is currently done. | 21:10 |
th1a | Anti-events seems like a good idea. | 21:11 |
thisfred | I was just thinking aloud, please ignore where inappropriate, or just plain dumb ;) | 21:11 |
alga | no, your idea makes a lot of sense actually | 21:12 |
th1a | I encourage you to think aloud. | 21:12 |
alga | for those corner cases, when all events are shrunk, and some removed, that's the model that does just fine | 21:12 |
alga | It's just that there's a lot of editing to do in a large school, so some automated tools might help | 21:13 |
th1a | One thing that would be nice is if the admin could say "I need to insert a 75 minute assembly at 2:00, without canceling any classes." | 21:14 |
th1a | Give me a modifed schedule for the day. | 21:14 |
thisfred | In an abstract sense, each instance of a recurring event is an event in itself, and could have special properties. (Next thursday's English will start 15 minutes late/in another room than usual) In that case you would need an anti-event, and a replacing event. | 21:14 |
th1a | Yeah. | 21:15 |
th1a | When the timetable for a day is rendered, It would have to check first for corresponding anti-events. | 21:15 |
alga | so, the question is: what happens more often: changes in the timetable or single-day exceptions? | 21:18 |
alga | my school was quite messy, and the timetable was not at all clear during the first two weeks of a term | 21:19 |
alga | but if everything would have been run properly, the timetable should have been finalized before the start of term | 21:20 |
thisfred | That would seem to be a general pattern. Errors (as in real world incosistrencies, rather than things which the appliction could/should have caught) tend to crop up early in a term and get hammered out. Rarely do they not occur at all | 21:21 |
thisfred | inconsistencies - application | 21:22 |
thisfred | will schooltool also teach spelling? | 21:22 |
alga | :) | 21:23 |
thisfred | wow,, that late already... sry all, I have to catch a train home. See you around | 21:25 |
<--thisfred has quit ("Farewell, cruel channel...") | 21:25 | |
th1a | I haven't seen many changes in the timetable once school started. | 21:38 |
th1a | Actually the teachers' union would never put up with that ahere anyhow. | 21:38 |
th1a | Single day exceptions are fairly frequent, though. A couple times a month. A lot more at the end of the school year and Christmas. | 21:39 |
<--stockholm (~andreas@petrus.schuldei.org) has left #schooltool ("ping timeout by peer") | 21:46 | |
---Disconnected (). | 22:10 | |
**** ENDING LOGGING AT Mon Jul 26 22:10:54 2004 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!