Difference between revisions of "2013 project rideshare breakout"
Jstirnaman (Talk | contribs) (→Participants) |
|||
| (14 intermediate revisions by 10 users not shown) | |||
| Line 1: | Line 1: | ||
| + | == Overview == | ||
| + | |||
The goal of the "Project Rideshare Board" was to create an application/environment/community to help enable institutions to collaborate on software development projects and foster technology mentorship/learning opportunities amongst libraries. | The goal of the "Project Rideshare Board" was to create an application/environment/community to help enable institutions to collaborate on software development projects and foster technology mentorship/learning opportunities amongst libraries. | ||
| − | One analogy of the project would be akin to | + | One analogy of the project would be akin to http://kickstarter.com/, although rather than soliciting financial contribution (although that ''may'' be what a particular institution wishes to contribute, say, for contracting some work, etc.) institutions would pledge what expertise, roles, and time commitment they could provide to help bring the project to fruition. |
| + | |||
| + | There was discussion over what the overall scope of what such an endeavor would entail; if and how libraries would break out of their current cultural habits of always going it alone; what technologies currently exist that could handle the needs of this; how participants would manage and mediate projects; and what would be needed to get started. | ||
| + | |||
| + | At the end, we decided what is necessary is a system that allows a project proposer to: | ||
| + | |||
| + | # Describe the project: what it is, some functional requirements, what "completion" means | ||
| + | # What you're bringing to the table | ||
| + | # What you need | ||
| + | |||
| + | There would also be some best practices documentation to improve the chances of project success, usefulness to the broadest audience (without losing the needs of the original proposers), least duplication of effort, and reusability of code/features. | ||
| + | |||
| + | We discussed the possibility of a core of volunteers that would keep an eye on projects and try to help keep the projects aligned with the best practices (if applicable) and perhaps lend guidance for certain groups. | ||
| + | |||
| + | == Participants == | ||
| + | |||
| + | * Ross Singer | ||
| + | * Rosalyn Metz | ||
| + | * Andrew Darby | ||
| + | * Chris Clement | ||
| + | * David Anderson | ||
| + | * Shaun Ellis | ||
| + | * Kevin Clarke | ||
| + | * Dave Menninger | ||
| + | * Peter Murray | ||
| + | * Ken Varnum (lurked quietly on the edges) | ||
| + | * Jason Stirnaman | ||
| + | |||
| + | == Next steps == | ||
| + | |||
| + | * Start a Google Group : DONE! [https://groups.google.com/forum/?fromgroups#!aboutgroup/code4lib-project-rideshare] | ||
| + | * ??? | ||
| + | * Launch the Rideshare Board! | ||
Latest revision as of 22:22, 27 February 2013
Overview
The goal of the "Project Rideshare Board" was to create an application/environment/community to help enable institutions to collaborate on software development projects and foster technology mentorship/learning opportunities amongst libraries.
One analogy of the project would be akin to http://kickstarter.com/, although rather than soliciting financial contribution (although that may be what a particular institution wishes to contribute, say, for contracting some work, etc.) institutions would pledge what expertise, roles, and time commitment they could provide to help bring the project to fruition.
There was discussion over what the overall scope of what such an endeavor would entail; if and how libraries would break out of their current cultural habits of always going it alone; what technologies currently exist that could handle the needs of this; how participants would manage and mediate projects; and what would be needed to get started.
At the end, we decided what is necessary is a system that allows a project proposer to:
- Describe the project: what it is, some functional requirements, what "completion" means
- What you're bringing to the table
- What you need
There would also be some best practices documentation to improve the chances of project success, usefulness to the broadest audience (without losing the needs of the original proposers), least duplication of effort, and reusability of code/features.
We discussed the possibility of a core of volunteers that would keep an eye on projects and try to help keep the projects aligned with the best practices (if applicable) and perhaps lend guidance for certain groups.
Participants
- Ross Singer
- Rosalyn Metz
- Andrew Darby
- Chris Clement
- David Anderson
- Shaun Ellis
- Kevin Clarke
- Dave Menninger
- Peter Murray
- Ken Varnum (lurked quietly on the edges)
- Jason Stirnaman
Next steps
- Start a Google Group : DONE! [1]
- ???
- Launch the Rideshare Board!
