Docksr: Difference between revisions
No edit summary |
mNo edit summary |
||
(One intermediate revision by one other user not shown) | |||
Line 5: | Line 5: | ||
Some of this functionality already exists, so a big part of it this project would be to identify existing open source options and then customize it to run on top of Google Drive and our existing project management interface ([http://www.redmine.org/ Redmine]). | Some of this functionality already exists, so a big part of it this project would be to identify existing open source options and then customize it to run on top of Google Drive and our existing project management interface ([http://www.redmine.org/ Redmine]). | ||
Why do we want to do this? The Berkman Center writes a lot of reports and academic papers. And when we write these reports, we then often generate a lot of other materials based on the original report (press releases, e-mails, websites, executive summaries, shorter versions of the report, etc.). When we write these smaller documents, we often need to use consistent language across all of the forms, which then creates significant problems when people make edits to a subsidiary documents. We need a way to keep track of documents and make sure that when changes occur in one, we know to also check all co-dependent documents. | Why do we want to do this? The Berkman Klein Center writes a lot of reports and academic papers. And when we write these reports, we then often generate a lot of other materials based on the original report (press releases, e-mails, websites, executive summaries, shorter versions of the report, etc.). When we write these smaller documents, we often need to use consistent language across all of the forms, which then creates significant problems when people make edits to a subsidiary documents. We need a way to keep track of documents and make sure that when changes occur in one, we know to also check all co-dependent documents. | ||
=== Ideal candidate criteria === | === Ideal candidate criteria === | ||
We are looking for candidates who are interested in solving workflow challenges and have experience building GUIs. In your proposal, please explain what approach you believe will be most successful to build Docksr. | |||
We are open to the mechanics of how you would design Docksr, so creativity and efficient use of time and resources are valued. | We are open to the mechanics of how you would design Docksr, so creativity and efficient use of time and resources are valued. |
Latest revision as of 10:08, 16 March 2017
We want to build software that will help us manage multiple inter-related documents.
It would most likely take the form of an overlay for Google Drive that allows us to keep track of dependencies between documents. This GUI would show how documents are related and allow on-click access to these documents (via either Google Docs or Word). It will also enable document versioning (define document B to be a new version of document A) to allow us keep track of versions in a non-destructive way.
Some of this functionality already exists, so a big part of it this project would be to identify existing open source options and then customize it to run on top of Google Drive and our existing project management interface (Redmine).
Why do we want to do this? The Berkman Klein Center writes a lot of reports and academic papers. And when we write these reports, we then often generate a lot of other materials based on the original report (press releases, e-mails, websites, executive summaries, shorter versions of the report, etc.). When we write these smaller documents, we often need to use consistent language across all of the forms, which then creates significant problems when people make edits to a subsidiary documents. We need a way to keep track of documents and make sure that when changes occur in one, we know to also check all co-dependent documents.
Ideal candidate criteria
We are looking for candidates who are interested in solving workflow challenges and have experience building GUIs. In your proposal, please explain what approach you believe will be most successful to build Docksr.
We are open to the mechanics of how you would design Docksr, so creativity and efficient use of time and resources are valued.