Docksr - Revision history

Griffin at 15:08, 16 March 2017

2017-03-16T15:08:50Z

← Older revision		Revision as of 15:08, 16 March 2017
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 ===

WikiSysop: /* Ideal candidate criteria */

2015-02-20T19:13:08Z

Ideal candidate criteria

← Older revision		Revision as of 19:13, 20 February 2015
Line 8:		Line 8:

	=== Ideal candidate criteria ===		=== Ideal candidate criteria ===
	~~Docksr is~~ 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 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.

WikiSysop at 18:47, 20 February 2015

2015-02-20T18:47:35Z

← Older revision		Revision as of 18:47, 20 February 2015
Line 1:		Line 1:
	We want to ~~write~~ an overlay for Google Drive that allows us to keep track of dependencies between documents. This GUI would show how documents are related ~~(document A is a superclass of document B)~~ 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.		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 ([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 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 ===
			Docksr is 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.

WikiSysop at 18:34, 20 February 2015

2015-02-20T18:34:44Z

← Older revision		Revision as of 18:34, 20 February 2015
Line 1:		Line 1:
	~~===== Project goal =====~~
	We want to write an overlay for Google Drive that allows us to keep track of dependencies between documents. This GUI would show how documents are related (document A is a superclass of document B) 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.		We want to write an overlay for Google Drive that allows us to keep track of dependencies between documents. This GUI would show how documents are related (document A is a superclass of document B) 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).		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]).

	~~===== Project background =====~~
	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 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.

WikiSysop at 18:33, 20 February 2015

2015-02-20T18:33:40Z

← Older revision		Revision as of 18:33, 20 February 2015
Line 1:		Line 1:
			===== Project goal =====
	We want to write an overlay for Google Drive that allows us to keep track of dependencies between documents. This GUI would show how documents are related (document A is a superclass of document B) 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.		We want to write an overlay for Google Drive that allows us to keep track of dependencies between documents. This GUI would show how documents are related (document A is a superclass of document B) 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.

WikiSysop: Created page with "We want to write an overlay for Google Drive that allows us to keep track of dependencies between documents. This GUI would show how documents are related (document A is a sup..."

2015-02-20T17:10:11Z

Created page with "We want to write an overlay for Google Drive that allows us to keep track of dependencies between documents. This GUI would show how documents are related (document A is a sup..."

New page

We want to write an overlay for Google Drive that allows us to keep track of dependencies between documents. This GUI would show how documents are related (document A is a superclass of document B) 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).

===== Project background =====
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.