*** replaceafill has left #schooltool | 01:05 | |
*** menesis has quit IRC | 01:39 | |
*** th1a has quit IRC | 03:11 | |
*** menesis has joined #schooltool | 08:57 | |
*** th1a has joined #schooltool | 11:41 | |
*** menesis has quit IRC | 13:21 | |
*** menesis has joined #schooltool | 14:29 | |
*** replaceafill has joined #schooltool | 14:32 | |
*** replaceafill has quit IRC | 15:15 | |
*** replaceafill has joined #schooltool | 15:27 | |
*** replaceafill has joined #schooltool | 15:27 | |
th1a | hi replaceafill, yvl, menesis. | 15:30 |
---|---|---|
th1a | Thanks for meeting a day later. | 15:30 |
replaceafill | good afternoon | 15:30 |
yvl | good morning / afternoon | 15:31 |
th1a | Couple things I don't want to forget. | 15:31 |
th1a | yvl, are we thinking you might have time for another task before the end of the year or does it look like it'll be all finishing temporal relationships and optimization? | 15:32 |
th1a | The only other thing that comes to mind for me would be maybe working on making imports use celery. | 15:32 |
yvl | I'll probably have a week or so to develop some other thing | 15:32 |
yvl | * or more | 15:32 |
th1a | Or for that matter just making sure replaceafill knows how to do it. | 15:32 |
yvl | also bugfixes | 15:32 |
th1a | OK, how does that sound? | 15:32 |
yvl | well | 15:33 |
yvl | I'm making imports use celery now :D | 15:33 |
th1a | Like today? | 15:33 |
yvl | yes | 15:33 |
* replaceafill remembers the importers were using celery at some point :) | 15:33 | |
yvl | yes | 15:33 |
yvl | just needs re-enabling, possibly cleanup | 15:33 |
th1a | Breaking up the team just when we get to the point of telepathy... | 15:34 |
th1a | *sigh* | 15:34 |
replaceafill | :D | 15:34 |
yvl | and since I'm updating import / export to handle temporal relationships... | 15:34 |
yvl | th1a :))) | 15:34 |
th1a | I'm working on the report for Mark. The core of it is just going to be going through the plan we came up with in 2011, which we've followed closely. | 15:35 |
th1a | It is actually pretty impressive. | 15:35 |
th1a | Or at least demonstrates some level of professional competence. ;-) | 15:35 |
yvl | cool :) | 15:35 |
th1a | We were pretty much on target for what needed to be done and how long it would take, although both the UI redesign and CanDo redesign became much more comprehensive than originally outlined. | 15:36 |
th1a | So I'll send you a draft of that overview so you guys can make sure I'm not giving us credit for anything we didn't do. | 15:36 |
yvl | sure | 15:37 |
th1a | OK. | 15:37 |
th1a | So I was looking at that starting bug with 12.04 that I missed and menesis responded to this morning. | 15:38 |
menesis | The bug had no information | 15:38 |
menesis | but I looked at errors.ubuntu.com and found a few reports there | 15:39 |
th1a | I'm working on a separate troubleshooting page for the book, but it also got me thinking that we should probably just stick on the Ubuntu 14.04 LTS and not support interim releases. | 15:39 |
th1a | Yeah! We never look at that! | 15:39 |
menesis | can you even access it? | 15:39 |
th1a | It wasn't the best bug report, but I should have flagged it. | 15:40 |
th1a | I've never tried to look. | 15:40 |
th1a | I guess you probably have to be an Ubuntu developer. | 15:40 |
th1a | So anyhow, I'm suggesting we won't do releases for 14.10 - 15.10. | 15:42 |
th1a | For that matter, are they switching from a six month cycle anyhow? | 15:42 |
th1a | I've kind of lost that thread. | 15:42 |
menesis | no, there were proposals about "rolling" release model | 15:43 |
menesis | but it got nowhere | 15:43 |
menesis | nothing is changing. interim releases have shortened support period | 15:43 |
menesis | (9 months) | 15:43 |
th1a | OK, so they're even less important. | 15:45 |
th1a | So I'm suggesting a pretty big change, which could include not worrying about a "major-ish" release every six months. | 15:46 |
th1a | We'll just put a new release in a new 14.04 repository whenever it is ready. | 15:46 |
th1a | And in theory get something new in 16.04 universe. | 15:46 |
th1a | You guys following me, replaceafill and menesis. | 15:47 |
replaceafill | yes | 15:47 |
menesis | that is what we have been doing for 12.04 users in the "dev" repository | 15:47 |
th1a | Yeah. | 15:48 |
menesis | the "stable" ppa has been neglected after the first round of bugfix releases | 15:49 |
menesis | usually | 15:49 |
th1a | Realistically we'll have fewer releases. | 15:49 |
th1a | I'd guess we'll do a 2.10 release in a year while we've still got a payroll... | 15:50 |
th1a | But it is going to slow down after that inevitably. | 15:50 |
th1a | Even if SchoolTool is healthy. | 15:50 |
menesis | a big part of this is that bzr does not support cherry-picking, so it's harder to track and backport bugfixes done after big features have landed on trunk | 15:50 |
th1a | It is going to be more client-work. | 15:50 |
th1a | OK. We can discuss this further, but I'm feeling a bit more secure on how we're not going to submerge under Ubuntu-administering. | 15:52 |
th1a | Also, Dave Welsh just announced he's directing a CanDo promotional video, which I think is an OUTSTANDING idea. | 15:53 |
replaceafill | i've been wondering about dwelsh :) | 15:53 |
th1a | That is, covering the history of the project. | 15:53 |
replaceafill | it's been a while since i heard from him | 15:53 |
th1a | Well, he was really upset about the slow start to the year. | 15:53 |
th1a | I gather. | 15:53 |
th1a | And felt like the problem was we'd misled him about whether the skills were going to be "stored in the year." | 15:54 |
th1a | Also, recovering from a traumatic brain injury. | 15:54 |
replaceafill | good point | 15:55 |
th1a | I think he felt like we'd already destroyed the project in his absence! | 15:55 |
th1a | But he's back on board. | 15:55 |
th1a | And God knows we need someone who knows how to sell! | 15:55 |
th1a | So that's good. | 15:55 |
th1a | OK, menesis, would you like to report? | 15:56 |
menesis | yes | 15:56 |
menesis | I have hunted down the "not starting after upgrade" bug | 15:57 |
menesis | was caused by the last commit before release of intervention :( | 15:57 |
th1a | Ah. The update you just did? | 15:58 |
menesis | that fixed a bug. so I've done that differently | 15:58 |
menesis | yes I've pushed a handful of fixes for intervention last Friday | 15:58 |
menesis | it works now | 15:59 |
th1a | OK. | 15:59 |
menesis | I've also added a patch to schooltool packages | 15:59 |
th1a | That was just for 12.04 that the bug came up? | 15:59 |
menesis | Failed to evolve to generation 42 | 15:59 |
menesis | Yes | 16:00 |
menesis | There were a few reports about that on errors.ubuntu.com, too | 16:00 |
menesis | Done with those critical issues | 16:01 |
th1a | You'd think we could get those injected into Launchpad. | 16:01 |
menesis | Maybe. Some errors are associated with launchpad bugs | 16:02 |
menesis | Have to look again | 16:02 |
th1a | OK. I didn't realize that data was there at all. | 16:03 |
menesis | This is where crashes are submitted | 16:03 |
menesis | by whoopsie daemon, I think | 16:03 |
menesis | Not sure if it is different than apport | 16:04 |
menesis | but with apport you get a dialog "Ubuntu has encountered an error" and can choose to report | 16:05 |
menesis | a browser window is opened with launchpad report bug, checked for duplicates, and you submit a bug by clicking a button | 16:06 |
th1a | Yeah. | 16:06 |
menesis | on final release apport is disabled, and reports are sent automatically to errors.ubuntu.com | 16:06 |
th1a | I've just not gotten that for SchoolTool before. | 16:06 |
menesis | but bugs are not filed | 16:07 |
th1a | OK, well something to keep an eye on I guess. | 16:07 |
th1a | Anything else, menesis? | 16:07 |
menesis | I've redone the jquery-ui upgrade that I had, pushed for replaceafill to see | 16:07 |
replaceafill | thanks menesis | 16:08 |
th1a | So basically we'll see that in the development trunk and hopefully find the remaining glitches? | 16:09 |
menesis | No I've pushed it to a branch | 16:09 |
menesis | Since I know there are issues | 16:10 |
th1a | OK. | 16:10 |
menesis | Looked what could be done to have uppercase symbols in journal, not decided case-insensitive dict or string, or a simple loop | 16:11 |
menesis | Looking at a crash with ldap but not sure how can I test it really works. Can make the parsing code smarter though. | 16:12 |
menesis | And that's all. | 16:12 |
th1a | OK, thanks menesis. | 16:13 |
th1a | replaceafill? | 16:13 |
replaceafill | ok | 16:13 |
replaceafill | first, i worked on the niepa update | 16:14 |
replaceafill | and last couple of days i fought David's demo database | 16:14 |
replaceafill | which has data from 2009... | 16:14 |
replaceafill | and at some point involved old cando | 16:14 |
replaceafill | i was like 'wtf?' when i saw IUniversalScoreSystem! | 16:15 |
th1a | I probably let you get too deep into that... | 16:15 |
replaceafill | we have no universal scoresystems anywhere! | 16:15 |
replaceafill | yeah | 16:15 |
replaceafill | that's why i ping'ed you yesterday | 16:15 |
replaceafill | i felt that way | 16:15 |
th1a | Well, that's the cost of pushing the meeting back I guess. | 16:15 |
replaceafill | and i decided to drop it at an acceptable point | 16:15 |
th1a | We just missed each other. | 16:15 |
th1a | OK. | 16:15 |
replaceafill | dont worry | 16:15 |
th1a | So it doesn't work. | 16:15 |
replaceafill | i didnt spend that much time on it | 16:16 |
th1a | OK. | 16:16 |
replaceafill | yes it does | 16:16 |
th1a | Good. | 16:16 |
th1a | OK. | 16:16 |
replaceafill | well, the reports are broken by the testing data | 16:16 |
replaceafill | but most of the functionality works with the demo db | 16:16 |
replaceafill | the update fully works with a fresh db ofc | 16:17 |
replaceafill | and current trunks attached | 16:17 |
replaceafill | i identified some improvements that niepa will need | 16:17 |
replaceafill | like update report styles ,etc | 16:17 |
replaceafill | but i guess we'll wait for that | 16:17 |
replaceafill | also, the code expects a single report sheet deployed | 16:17 |
replaceafill | and breaks when there are more | 16:17 |
replaceafill | and so on | 16:17 |
replaceafill | ok, now level memberships | 16:18 |
replaceafill | i started working with yvl's temporal branch | 16:19 |
replaceafill | and i also identified a few things i want to mention | 16:19 |
replaceafill | yvl is probably aware of most | 16:19 |
replaceafill | like the importer update | 16:19 |
th1a | Telepathically? | 16:20 |
replaceafill | the addTeacher.html, addStudent.html and addAdministrator.html are broken | 16:20 |
replaceafill | :D | 16:20 |
yvl | :D | 16:20 |
replaceafill | we need some css fixes for dialogs | 16:20 |
replaceafill | (the dropdown fonts are too big) | 16:20 |
replaceafill | i was thinking of sorting the states alphabetically | 16:21 |
replaceafill | but then i noticed they're stored in orderedcontainers | 16:21 |
replaceafill | any reason for the ordering yvl? | 16:21 |
yvl | no | 16:22 |
yvl | well, internally - yes | 16:22 |
yvl | first active and first inactive are used by default | 16:22 |
yvl | in some rare views | 16:23 |
replaceafill | ah | 16:23 |
yvl | well not that rare | 16:23 |
replaceafill | i wanted to ask about the default option too | 16:23 |
yvl | also | 16:23 |
yvl | it seemed to me that the states should be ordered "logically" instead of alphabetically | 16:24 |
yvl | hence the ability to configure order | 16:24 |
th1a | That is reasonable. | 16:25 |
replaceafill | do you think we should add that ability to the edit view of the states? | 16:25 |
replaceafill | i mean, ability to change the sorting | 16:25 |
yvl | umm | 16:25 |
yvl | you mean extra UI? | 16:25 |
replaceafill | yes, like we do with worksheets in the gradebook for example | 16:26 |
yvl | now you have to use cut-paste | 16:26 |
yvl | yeah, it would make sense | 16:26 |
replaceafill | ok, just a thought :) | 16:26 |
replaceafill | oh | 16:26 |
replaceafill | a couple of forms are broken | 16:26 |
replaceafill | (add/edit for levels) | 16:26 |
replaceafill | because of a change in the flourish.form.Form class | 16:26 |
replaceafill | which nows inherits from PageBase | 16:27 |
replaceafill | instead of Page | 16:27 |
replaceafill | the template changed and those level forms don't declare it explicitly | 16:27 |
replaceafill | also, the date column in the "Assign <person>" dialog should be in YYYY-MM-DD format | 16:28 |
replaceafill | imho :) | 16:28 |
replaceafill | so, i started with levels membership adding a "levels" relationship property | 16:29 |
replaceafill | but my question here is more about UI | 16:29 |
replaceafill | is it ok if i add just a level dropdown to the add person view | 16:29 |
replaceafill | and set the state to active automatically? | 16:30 |
replaceafill | so far i've only added three states for level membership: | 16:30 |
th1a | The user doesn't want to know about active and inactive levels. | 16:30 |
th1a | That's an implementation artifact. | 16:30 |
yvl | the question here is pre-enrolled/enrolled on <date> rather then active/inactive | 16:31 |
yvl | add person and make him enter level 4 on today by default | 16:32 |
th1a | yesh | 16:32 |
th1a | yes | 16:32 |
yvl | yesh also works | 16:32 |
replaceafill | ok, that's what i meant | 16:32 |
replaceafill | a single dropdown | 16:32 |
replaceafill | just levels | 16:32 |
replaceafill | user doesn't see dates or states | 16:32 |
replaceafill | but if i have 3 states: | 16:33 |
replaceafill | pre-enrolled/enrolled/graduated | 16:33 |
replaceafill | i was wondering if we need the 'pre-enrolled' one? | 16:33 |
th1a | I'm afraid I need a brief reminder on why the levels aren't states themselves. | 16:34 |
th1a | Right? | 16:35 |
yvl | states of relationship between student and what? | 16:36 |
replaceafill | states are relationships, right? | 16:37 |
replaceafill | yes | 16:37 |
th1a | OK, I've confused everything. | 16:37 |
replaceafill | telephaty! | 16:37 |
replaceafill | :D | 16:37 |
yvl | :D | 16:37 |
th1a | OK. | 16:37 |
th1a | Right, the relationship is to the level. | 16:37 |
th1a | OK. | 16:37 |
th1a | Right. | 16:37 |
replaceafill | ok | 16:37 |
th1a | I'm back on track. | 16:37 |
replaceafill | do we need 'pre-enrolled'? | 16:37 |
replaceafill | for levels <-> persons? | 16:37 |
yvl | good question | 16:38 |
yvl | pre-enrolled could be used to mark "should become level X at some point" | 16:38 |
yvl | "don't know when exactly" | 16:38 |
yvl | "but want to mark that student should become level X" | 16:39 |
replaceafill | yvl, if i define the states like this: | 16:39 |
replaceafill | states.add(_('Pre-enrolled'), INACTIVE+PREENROLLED, 'p') | 16:39 |
replaceafill | states.add(_('Enrolled'), ACTIVE, 'a') | 16:39 |
replaceafill | states.add(_('Graduated'), INACTIVE+GRADUATED, 'c') | 16:39 |
replaceafill | there's logic to get me the first (and only) active one? | 16:40 |
replaceafill | i mean, methods in the machinery | 16:40 |
yvl | you should add a pure inactive state | 16:40 |
replaceafill | ah ok | 16:40 |
yvl | it's a questionable implementation | 16:41 |
yvl | but we don't REMOVE temporal relationships anymore | 16:41 |
yvl | it's more of an "archive" | 16:41 |
yvl | you can make it inactive from day X forward | 16:42 |
yvl | but the history stays | 16:42 |
replaceafill | so, suppose i add the student to level 3 | 16:42 |
replaceafill | then i realize he should go to level 5 | 16:42 |
replaceafill | (it was an accident) | 16:42 |
replaceafill | i'd need to set the level 3 state to inactive from the same date | 16:43 |
replaceafill | correct? | 16:43 |
yvl | yes | 16:43 |
replaceafill | and set a new one to level 5 as active | 16:43 |
yvl | yes | 16:43 |
replaceafill | got it | 16:43 |
yvl | users can actually add states named "FIX ACCIDENT" (inactive) | 16:43 |
replaceafill | i was thinking of adding that logic to the person "edit" view | 16:44 |
replaceafill | ah | 16:44 |
yvl | and we can add "delete history" link / button later on | 16:44 |
replaceafill | maybe i'm trying to hide too much behind a dropdown | 16:44 |
yvl | that would actually destory the relationshpi | 16:44 |
th1a | Ideally a lot would be hidden behind the dropdown. | 16:45 |
replaceafill | ah ok | 16:45 |
replaceafill | i guess i'm on the right track then :) | 16:45 |
replaceafill | oh | 16:45 |
yvl | yeah :) | 16:45 |
th1a | Being able to do a pending change to a new level is a potential feature, but perhaps an absurdly advanced one. | 16:45 |
replaceafill | level information in the index view for persons? | 16:46 |
yvl | but availabilty of pure ACTIVE and pure INACTIVE states is kind of assumed everywhere now | 16:46 |
th1a | replaceafill: Yes. | 16:46 |
replaceafill | th1a, where? | 16:46 |
replaceafill | new accordion? | 16:46 |
replaceafill | under sections? | 16:47 |
replaceafill | i don't see it as personal information :D | 16:47 |
yvl | subtitle of the page? | 16:47 |
replaceafill | :O | 16:47 |
yvl | or at least in general information? | 16:47 |
yvl | it's one of the most basic things | 16:47 |
th1a | It is basic, to be sure. | 16:47 |
yvl | John Brown, the 6th-grader | 16:47 |
replaceafill | subtitle sounds nice :) | 16:48 |
th1a | Try that. | 16:49 |
replaceafill | cool | 16:49 |
replaceafill | will do | 16:49 |
replaceafill | and last but not least | 16:49 |
replaceafill | jelkner | 16:49 |
replaceafill | :) | 16:49 |
replaceafill | th1a, he's requesting help | 16:49 |
replaceafill | with the feature we developed at pycon | 16:49 |
replaceafill | now that he has lots of student data | 16:49 |
replaceafill | it seems like the update is not calculating the grades correctly | 16:50 |
replaceafill | (that is cando grades from quiz answers) | 16:50 |
replaceafill | so he asked me to look into that | 16:50 |
th1a | Well, I have you jumping around a bit anyhow, so go ahead and squeeze it in wherever. | 16:51 |
replaceafill | cool | 16:51 |
replaceafill | thanks | 16:51 |
* replaceafill done | 16:51 | |
th1a | At some point David is going to actually tell me what he needs and when. | 16:51 |
th1a | Thanks replaceafill. | 16:51 |
replaceafill | :) | 16:51 |
th1a | yvl? | 16:51 |
yvl | did some cleanup | 16:51 |
yvl | wrote contact evolution | 16:51 |
yvl | now contact relationships are fully ported to configurable ones | 16:52 |
yvl | and now working on the exporter and importer | 16:52 |
yvl | groups, section enrollment and contact relationships need updating | 16:52 |
yvl | the idea is to add a list of date / code pairs | 16:53 |
yvl | next to student id for example | 16:53 |
yvl | and codes would be ones that can be configured by the user | 16:53 |
yvl | so there is one interesting edge case | 16:54 |
yvl | where users delete some relationship status codes | 16:54 |
th1a | Oh... yes... that does complexify things! | 16:54 |
yvl | since system stores both "meaning" and "code" | 16:54 |
yvl | and should query by "meaning" | 16:55 |
yvl | after deletion, in many views the text should change | 16:55 |
yvl | but not the way it works | 16:55 |
yvl | to explain: | 16:55 |
yvl | say we have a state... | 16:56 |
yvl | signed-up (to a section, but not payed yet), INACTIVE, code "si" | 16:56 |
yvl | exporting, it would have si in XLS | 16:56 |
yvl | in views it would be displayed as "signed up" | 16:56 |
yvl | but in some views it would be hidden, because it's INACTIVE | 16:57 |
yvl | if user deletes that state | 16:57 |
yvl | in some views it would be displayed as "Inactive" | 16:57 |
yvl | in others - still hidden | 16:57 |
yvl | in XLS it would be "si" | 16:58 |
yvl | BUT | 16:58 |
yvl | you could not reimport | 16:58 |
yvl | untill you correct the XLS | 16:58 |
th1a | OK. | 16:58 |
yvl | or add a "si" code back to the system | 16:58 |
th1a | Are we putting history in xls? | 16:58 |
yvl | yes | 16:58 |
yvl | also "the future" | 16:58 |
yvl | adding temporal relationship is like adding past/future tenses to the language | 16:58 |
yvl | there is also another edge case | 16:59 |
yvl | related to how we should import | 16:59 |
yvl | should we overwrite history? | 16:59 |
yvl | or merge it? | 16:59 |
yvl | if users want to pre-enroll students to some section | 17:00 |
yvl | in case of merging | 17:00 |
yvl | they would make a simple XLS | 17:00 |
yvl | write date / "preenrolledcode" next to student | 17:00 |
yvl | and import | 17:00 |
yvl | in case of overwriting | 17:00 |
yvl | they would have to export the section | 17:00 |
yvl | then add pre-enroll states | 17:00 |
yvl | then import back again | 17:00 |
yvl | drawbacks of merging are that it's not that transparent | 17:01 |
th1a | We shouldn't overwrite history. | 17:01 |
yvl | example: | 17:01 |
th1a | Feel free to throw errors. | 17:01 |
yvl | you pre-enroll student next month | 17:01 |
yvl | forget about that | 17:01 |
yvl | import students to sections | 17:01 |
th1a | The reason we use XLS is we can make people fix it manually. | 17:01 |
yvl | with some states | 17:02 |
yvl | and after a month suddenly some students become pre-enrolled | 17:02 |
yvl | you could fix that by export-fix-import of course | 17:02 |
yvl | the third option would be to overwrite future, merge history | 17:03 |
th1a | Hrm... | 17:03 |
yvl | not sure if it's intuitive | 17:03 |
th1a | I would be very conservative about this. | 17:03 |
th1a | I don't want it to be a big source of "power user" tricks. | 17:03 |
yvl | true | 17:04 |
th1a | I'm afraid I have to go. | 17:04 |
yvl | so that's something to think about | 17:04 |
yvl | ok | 17:05 |
* yvl done actually | 17:05 | |
th1a | You could easily convince me that export/import doesn't need history. | 17:05 |
th1a | I don't know if that even makes anything easier. | 17:05 |
th1a | OK, Thanks guys! | 17:05 |
th1a | Talk to you Monday. Have a good week/end! | 17:06 |
* th1a drops the bag of gravel. | 17:06 | |
replaceafill | thanks everybody | 17:06 |
yvl | thanks | 17:06 |
yvl | see you all soon | 17:06 |
yvl | replaceafill, if you run into some can of worms, ping me! | 17:06 |
replaceafill | will do :) | 17:06 |
*** replaceafill has quit IRC | 17:11 | |
*** yvl has quit IRC | 17:11 | |
*** replaceafill has joined #schooltool | 17:11 | |
*** mattva01 has joined #schooltool | 23:04 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!