| 1 | = Meet Ups = |
| 2 | |
| 3 | == 2300 UTC 2nd May 2010 (4pm PDT) == |
| 4 | |
| 5 | Parallel to the SSF Annual Meeting. Hopefully there will a few people at the meeting who can jump on IRC and keep us updated virtually! |
| 6 | |
| 7 | == 0600 UTC 17th April 2010 == |
| 8 | === Agenda === |
| 9 | * Introductions |
| 10 | * Open |
| 11 | * Wiki - How can we make it better? |
| 12 | * (please enter your questions or what you would like to share/discuss here) |
| 13 | * Say I have an arbitrary SQL query involving multiple tables. I would like to hand it to the database, then be able to use the result, e.g. as a view. (I don't necessarily just want to display this as a list in a form -- it might be an intermediate step in business logic.) How do I 1) get the query executed? 2) access the result? 3) use it in a form? |
| 14 | * Are we still interested in a [WorkOutIdeas Work Out]? Date? What outputs should we try to achieve? |
| 15 | * New name. |
| 16 | * Follow-Up Activities |
| 17 | === Outcomes === |
| 18 | * Pat raised a good question about SQL queries, which has since kicked off it’s own email thread. |
| 19 | * Robby and Gavin had a good discussion about how the survey tool could be extended to share data in EDXL messages. This is probably beyond the scope of a GSOC project, but good to keep in mind for the design. |
| 20 | * Michael suggested using S3XRC for Shikhark’s importer project in order to enforce data validation. |
| 21 | * Documentation |
| 22 | * Praneeth recommended that code is “scrubbed” and has better comments and doc-strings. |
| 23 | * Gavin commented that there were too many links. |
| 24 | * There was a request for better basic documentation on BZR |
| 25 | * Revision of documentation is best to wait until the SFF has decided on standard infrastructure. |
| 26 | * It was agreed that it would be good for people to email this list to inform the community what they were working on |
| 27 | * Weekly emails are possibly excessive for volunteers, but will be required from GSOC students. |
| 28 | * Definitely notify the list when you add new features |
| 29 | * Notify the list when you start, complete or give up on projects. This will hopefully increase collaboration and reduce overlap. |
| 30 | |