Projectdb: Difference between revisions
(..) |
(update reality!) |
||
(13 intermediate revisions by 4 users not shown) | |||
Line 3: | Line 3: | ||
It is currently being used as our live [[contributors program]]/developers-program interface. Over the past week it has processed 100 applications from LinuxTag. |
It is currently being used as our live [[contributors program]]/developers-program interface. Over the past week it has processed 100 applications from LinuxTag. |
||
The code base was given over to OLPC including he database by Aaron Kaplan and Chris Hager, who were the main developers. |
|||
The codebase is currently only partly open, as git access is not generally available. The code is being cleaned up this week to accomodate important feature requests. |
|||
REMARK: SJ *believes* the code is only partly open . In fact it is. But I just have a roadmap for it for initial release. And that roadmap will be followed in order to assure some quality. [[User:213.47.53.193|213.47.53.193]] 15:39, 7 June 2008 (EDT) |
|||
Todo: extend the curent data model to cover further aspects of projects, including the stage of completion, idea through implementation, initiatives and trials, as well as projects that require new hardware to get underway. |
|||
== code == |
|||
'''[[Media:Projectdb.tgz|The original code is available for reference]]''' -- Dogi is working on new code based on this and Pia W / John Ferlito areworking on a library toolkit for friends of OLPC in Oz. |
|||
== general db == |
== general db == |
||
A further extension of a shared database should cover information about all the data that is core to OLPC: |
A further extension of a shared database should cover information about all the data that is core to OLPC: |
||
* projects - |
* projects - iedeas, development, creation; initiatives, trials, research |
||
* parts - XOs, spares, peripherals, power |
* parts - XOs, spares, peripherals, power |
||
* places - countries, cities, schools |
* places - countries, cities, schools |
||
Line 19: | Line 20: | ||
== current use == |
== current use == |
||
A half-dozen people are reading data from the current |
A half-dozen people are reading data from the current interface and hand-parsing it into xls formats to satisfy a partly in-flux Brightstar process; this will eventually be done via xml (with xml export to B* and xml import from them for confirmation of receipt and shipping). This could be improved; see notes and bugs below: |
||
== roadmap == |
|||
=== bug fixing === |
|||
* List the proposer's name on the proposer detail page |
|||
* Make all tables sortable by column |
|||
* Provide exports of any viewed table to csv (or xls?) as well as B*-xml |
|||
* Show the date of application and of last update |
|||
* Fix the apostrophe- and slash-escaping bug in form data |
|||
* Zip code field in profile page can't be used for postal addresses of non-US countries. If a non-US country's postal address is entered, it places the project in North America on Google Maps. |
|||
=== features === |
|||
* Let admins create new admins or new accounts by email |
|||
* Let admins see all users on the system; separate from the list of people who sign up and submit a project |
|||
* Show users their own profile with more active focus on the status of their applications (or the fact that they haven't submitted one yet!) and a visualization of the timelines they suggest' |
|||
* Ask users to define fixed dates, in addition to durations, for projects. Expand data model accordingly |
|||
* Add both personal and project mailing addresses and phone #s. |
|||
=== Data specification for processing projectdb requests === |
|||
The process of requesting XOs currently is passed on to B* via spreadsheet. They are working on an xml solution that will accept and generate XML lists to automate the process. |
|||
: NOTE by Aaron: we have been pushing SJ for literally *months* to get a proper specification from B*. This sucks! Suddenly everything has to be done very very fast and the two main developers are not given any time to prepare a proper release. (unsigned by [[user:aaronKaplan|aaronKaplan]]) |
|||
:: Yes, this is a problem. I still don't have those specifications; so we have to make do with what is currently required (csv --> xls, split up by country). |
|||
{{Stub}} |
{{Stub}} |
Latest revision as of 23:50, 5 April 2010
The projectdb (alpha name) is a database designed to capture and track requests for XOs.
It is currently being used as our live contributors program/developers-program interface. Over the past week it has processed 100 applications from LinuxTag.
The code base was given over to OLPC including he database by Aaron Kaplan and Chris Hager, who were the main developers.
Todo: extend the curent data model to cover further aspects of projects, including the stage of completion, idea through implementation, initiatives and trials, as well as projects that require new hardware to get underway.
code
The original code is available for reference -- Dogi is working on new code based on this and Pia W / John Ferlito areworking on a library toolkit for friends of OLPC in Oz.
general db
A further extension of a shared database should cover information about all the data that is core to OLPC:
- projects - iedeas, development, creation; initiatives, trials, research
- parts - XOs, spares, peripherals, power
- places - countries, cities, schools
- people - individual teacher, developers; organizations, partners; chapters, interest groups
current use
A half-dozen people are reading data from the current interface and hand-parsing it into xls formats to satisfy a partly in-flux Brightstar process; this will eventually be done via xml (with xml export to B* and xml import from them for confirmation of receipt and shipping). This could be improved; see notes and bugs below:
roadmap
bug fixing
- List the proposer's name on the proposer detail page
- Make all tables sortable by column
- Provide exports of any viewed table to csv (or xls?) as well as B*-xml
- Show the date of application and of last update
- Fix the apostrophe- and slash-escaping bug in form data
- Zip code field in profile page can't be used for postal addresses of non-US countries. If a non-US country's postal address is entered, it places the project in North America on Google Maps.
features
- Let admins create new admins or new accounts by email
- Let admins see all users on the system; separate from the list of people who sign up and submit a project
- Show users their own profile with more active focus on the status of their applications (or the fact that they haven't submitted one yet!) and a visualization of the timelines they suggest'
- Ask users to define fixed dates, in addition to durations, for projects. Expand data model accordingly
- Add both personal and project mailing addresses and phone #s.