Rough Draft This is a first attempt at a well-documented way for people to post suggested improv...
Public Lab is an open community which collaboratively develops accessible, open source, Do-It-Yourself technologies for investigating local environmental health and justice issues.
| 6 CURRENT | liz |
March 01, 2016 22:14
| over 8 years ago
Rough DraftThis is a first attempt at a well-documented way for people to post suggested improvements to Public Lab tools, so that they may be integrated into a "base design" -- which will also be the version the Kits Initiative will produce and ship. Leave a comment on this post if you'd like to be involved -- this workflow is evolving! Overview
Public dialogue about design goalsAs part of technical scoping, and defining what problem a technique / technology addresses, each tool should have at the top of its wiki page the following sections, and discuss these publicly on lists and in notes/comments as part of public dialogue about design goals:
Project maintainers
Great question. Borrowing from the free software world we're proposing that each project will have a "maintainer" who's the point person for reviewing and merging updates, communicating, documentation, etc. That's not to say they'll be a monarch -- maintainers' main job will be communicating between contributors, supporting and shepherding new contributions, and above all transparency -- keeping the community up to date on the roadmap, development progress and active design discussions. It'll also be their job to ensure that there's a broad base of contribution. If it's too hard to contribute, because the design files are too hard to find or read, or require expensive tools to edit, or because submissions are shouted down by an unfriendly and unhelpful gang of jargon-wielding technocrats, that's a problem! We're hoping to use this project as a pilot to set some standards for openness and accessibility. For the Spectrometer project, the maintainer will be @warren, and such documentation is forthcoming -- see below! How to contributeWe'll soon be posting draft documentation on how to edit the source production files, but basically we're going to use specially-tagged research notes as To be accepted and merged into the production version, a proposal will have to meet the kit's cost, complexity, materials, and processes specifications. Part of the project team's job is to clearly document these, and to keep them simple and affordable. Actually, those are our first specs; so far, we're thinking that proposed changes must be:
These requirements ensure that proposals meet some of our broader project goals of accessibility and cost, but also ensure that the Public Lab Kits Initiative can actually reasonably incorporate and manufacture the changes, and can plan around a known timeline. But never fear -- we'll work with folks to refine their proposals to be compatible -- that's part of the maintainer's responsibility, as mentioned above. Ideally, and eventually, each tool page following this methodology will display:
Projects using this methodologySpectrometerWe're piloting this workflow with the Public Lab Spectrometer project, but leave a comment here if you'd like a project your involved in to follow it too. For the spectrometer project, tag your proposed upgrades with Riffle DataloggerJust getting underway (March 2016), not yet incorporated onto http://publiclab.org/wiki/riffle |
Revert | |
| 5 | liz |
March 01, 2016 22:01
| over 8 years ago
Rough DraftThis is a first attempt at a well-documented way for people to post suggested improvements to Public Lab tools, so that they may be integrated into a "base design" -- which will also be the version the Kits Initiative will produce and ship. Leave a comment on this post if you'd like to be involved -- this workflow is evolving! Overview
Public dialogue about design goalsAs part of technical scoping, and defining what problem a technique / technology addresses, each tool should have at the top of its wiki page the following sections, and discuss these publicly on lists and in notes/comments as part of public dialogue about design goals:
Project maintainers
Great question. Borrowing from the free software world we're proposing that each project will have a "maintainer" who's the point person for reviewing and merging updates, communicating, documentation, etc. That's not to say they'll be a monarch -- maintainers' main job will be communicating between contributors, supporting and shepherding new contributions, and above all transparency -- keeping the community up to date on the roadmap, development progress and active design discussions. It'll also be their job to ensure that there's a broad base of contribution. If it's too hard to contribute, because the design files are too hard to find or read, or require expensive tools to edit, or because submissions are shouted down by an unfriendly and unhelpful gang of jargon-wielding technocrats, that's a problem! We're hoping to use this project as a pilot to set some standards for openness and accessibility. For the Spectrometer project, the maintainer will be @warren, and such documentation is forthcoming -- see below! How to contributeWe'll soon be posting draft documentation on how to edit the source production files, but basically we're going to use specially-tagged research notes as To be accepted and merged into the production version, a proposal will have to meet the kit's cost, complexity, materials, and processes specifications. Part of the project team's job is to clearly document these, and to keep them simple and affordable. Actually, those are our first specs; so far, we're thinking that proposed changes must be:
These requirements ensure that proposals meet some of our broader project goals of accessibility and cost, but also ensure that the Public Lab Kits Initiative can actually reasonably incorporate and manufacture the changes, and can plan around a known timeline. But never fear -- we'll work with folks to refine their proposals to be compatible -- that's part of the maintainer's responsibility, as mentioned above. Ideally, and eventually, each tool page following this methodology will display:
Projects using this methodologySpectrometerWe're piloting this workflow with the Public Lab Spectrometer project, but leave a comment here if you'd like a project your involved in to follow it too. For the spectrometer project, tag your proposed upgrades with RiffleJust getting underway (March 2016), not yet incorporated onto http://publiclab.org/wiki/riffle |
Revert | |
| 4 | warren |
November 22, 2015 15:47
| about 9 years ago
Rough DraftThis is a first attempt at a well-documented way for people to post suggested improvements to Public Lab tools, so that they may be integrated into a "base design" -- which will also be the version the Kits Initiative will produce and ship. Leave a comment on this post if you'd like to be involved -- this workflow is evolving! OverviewFor now, we're piloting this workflow with the Public Lab Spectrometer project, but leave a comment here if you'd like a project your involved in to follow it too. Basically, we'd like:
Project maintainers
Great question. Borrowing from the free software world we're proposing that each project will have a "maintainer" who's the point person for reviewing and merging updates, communicating, documentation, etc. That's not to say they'll be a monarch -- maintainers' main job will be communciating between contributors, supporting and sheparding new contributions, and above all transparency -- keeping the community up to date on the roadmap, development progress and active design discussions. It'll also be their job to ensure that there's a broad base of contribution. If it's too hard to contribute, because the design files are too hard to find or read, or require expensive tools to edit, or because submissions are shouted down by an unfriendly and unhelpful gang of jargon-wielding technocrats, that's a problem! We're hoping to use this project as a pilot to set some standards for openness and accessibility. For the Spectrometer project, the maintainer will be @warren, and such documentation is forthcoming -- see below! How to contributeWe'll soon be posting draft documentation on how to edit the source production files, but basically we're going to use specially-tagged research notes as To be accepted and merged into the production version, a proposal will have to meet the kit's cost, complexity, materials, and processes specifications. Part of the project team's job is to clearly document these, and to keep them simple and affordable. Actually, those are our first specs; so far, we're thinking that proposed changes must be:
These requirements ensure that proposals meet some of our broader project goals of accessibility and cost, but also ensure that the Public Lab Kits Initiative can actually reasonably incorporate and manufacture the changes, and can plan around a known timeline. But never fear -- we'll work with folks to refine their proposals to be compatible -- that's part of the maintainer's responsibility, as mentioned above. Ideally, and eventually, each tool page following this methodology will display:
For now, for the spectrometer project, tag your proposed upgrades with |
Revert | |
| 3 | warren |
November 22, 2015 15:41
| about 9 years ago
Rough DraftThis is a first attempt at a well-documented way for people to post suggested improvements to Public Lab tools, so that they may be integrated into a "base design" -- which will also be the version the Kits Initiative will produce and ship. Leave a comment on this post if you'd like to be involved -- this workflow is evolving! OverviewBasically, we'd like:
Project maintainers
Great question. Borrowing from the free software world we're proposing that each project will have a "maintainer" who's the point person for reviewing and merging updates, communicating, documentation, etc. That's not to say they'll be a monarch -- maintainers' main job will be communciating between contributors, supporting and sheparding new contributions, and above all transparency -- keeping the community up to date on the roadmap, development progress and active design discussions. It'll also be their job to ensure that there's a broad base of contribution. If it's too hard to contribute, because the design files are too hard to find or read, or require expensive tools to edit, or because submissions are shouted down by an unfriendly and unhelpful gang of jargon-wielding technocrats, that's a problem! We're hoping to use this project as a pilot to set some standards for openness and accessibility. For the Spectrometer project, the maintainer will be @warren, and such documentation is forthcoming -- see below! How to contributeWe'll soon be posting draft documentation on how to edit the source production files, but basically we're going to use specially-tagged research notes as To be accepted and merged into the production version, a proposal will have to meet the kit's cost, complexity, materials, and processes specifications. Part of the project team's job is to clearly document these, and to keep them simple and affordable. Actually, those are our first specs; so far, we're thinking that proposed changes must be:
These requirements ensure that proposals meet some of our broader project goals of accessibility and cost, but also ensure that the Public Lab Kits Initiative can actually reasonably incorporate and manufacture the changes, and can plan around a known timeline. But never fear -- we'll work with folks to refine their proposals to be compatible -- that's part of the maintainer's responsibility, as mentioned above. Ideally, and eventually, each tool page following this methodology will display:
For now, for the spectrometer project, tag your proposed upgrades with |
Revert | |
| 2 | warren |
November 22, 2015 15:37
| about 9 years ago
Rough DraftThis is a first attempt at a well-documented way for people to post suggested improvements to Public Lab tools, so that they may be integrated into a "base design" -- which will also be the version the Kits Initiative will produce and ship. Leave a comment on this post if you'd like to be involved -- this workflow is evolving! OverviewBasically, we'd like:
Project maintainers
Great question. Borrowing from the free software world we're proposing that each project will have a "maintainer" who's the point person for reviewing and merging updates, communicating, documentation, etc. That's not to say they'll be a monarch -- maintainers' main job will be communciating between contributors, supporting and sheparding new contributions, and above all transparency -- keeping the community up to date on the roadmap, development progress and active design discussions. It'll also be their job to ensure that there's a broad base of contribution. If it's too hard to contribute, because the design files are too hard to find or read, or require expensive tools to edit, or because submissions are shouted down by an unfriendly and unhelpful gang of jargon-wielding technocrats, that's a problem! We're hoping to use this project as a pilot to set some standards for openness and accessibility. For the Spectrometer project, the maintainer will be @warren, and such documentation is forthcoming -- see below! How to contributeWe'll soon be posting draft documentation on how to edit the source production files, but basically we're going to use specially-tagged research notes as To be accepted and merged into the production version, a proposal will have to meet the kit's cost, complexity, materials, and processes specifications. Part of the project team's job is to clearly document these, and to keep them simple and affordable. Actually, those are our first specs; so far, we're thinking that proposed changes must be:
These requirements ensure that proposals meet some of our broader project goals of accessibility and cost, but also ensure that the Public Lab Kits Initiative can actually reasonably incorporate and manufacture the changes, and can plan around a known timeline. But never fear -- we'll work with folks to refine their proposals to be compatible -- that's part of the maintainer's responsibility, as mentioned above. Ideally, and eventually, each tool page following this methodology will display:
For now, tag your proposed upgrades with |
Revert | |
| 1 | warren |
November 16, 2015 19:26
| about 9 years ago
Coming soon!Check out the talk page for early drafts, and leave a comment on this post if you'd like to be involved. Also see Contributing to Public Lab Software upon which this page is loosely based! |
Revert | |
| 0 | warren |
November 16, 2015 19:25
| about 9 years ago
Coming soon!Check out the talk page for early drafts, and leave a comment on this post if you'd like to be involved. |
Revert |