Re: [DIYbio] Anyone know a good.spam free Wiki like Database for storing experiments and data?

On 05/31/2014 10:30 AM, Connor Dickie wrote:
> One thing we do do is allow people to "branch" or "fork" (to use git parlance) lab books that have been listed under an open CC
> license.

Using version control could be useful as is to some people, but most researchers
would want some of git's complexity hidden in day to day use.
The terminology to describe notebooks could sound like:

Contribute and share an existing lab notebook, or start your own version?

Are you ready to publish results alongside others in the main project notebook?
Yes --> Which pages to publish? No--> What pages are ready for publishing in your notebook
to be called final, and what is still draft quality?
(Shows GUI for checking off status of pages, or selected text, etc.)

Some GUI menu choice for the notebook would show "all" including rough drafts, or final, hiding rough draft parts.

At individual contributor merge time, no interweaving of writings diagrams, photos,
data is done, it just becomes available for editing in the main notebook.
At publishing time those that have permission to edit it there
can merge into one cohesive document describing the work of all contributors together.

After individual contributor merges, changes to the separate individual contributor notebook would
trigger a merge reconciliation at any attempt to publish the current newer status of
work in the individual notebook. Merge reconciliation would require at-the-same-time
authorization of both the overall project leader and the individual, and would be like
software code merging -- not necessarily easy for some folks to do. It might not be automatable
to have new writings flow into the main document from the individual contrib notebook.

Probably the best way to handle merges by individual contribs is that they get the entire contents
of the main doc version control and the main notebook gets all their content also.
Then they have their version of it as a branch. They can set things so they only see their branch,
or they can work in the main notebook. When using the main notebook, they would add to their
project contrib dir, (see below).
Then the easiest way forward is to do all edits in the main notebook and abandon
the individual branch after the first "for publication" merge.

Some would want to share data before ready for publication. If it just went into
a contributor data part of the main notebook, with no parts referenced in the main
notebook, merging would be easy, and only require authorization of the contributor.
After using some of a contributor's writings and data in the main doc,
merging gets more difficult again, the same as when ready to publish.

I can see multiple contributors to a project being easy up until the overall writing
that pulls the project together is done, then it gets messy. To keep sharing progress easy,
building the idea of project contributor directories into a notebook makes sense to me.
Then merges of info to share require only an individual contributor's OK.

--
-- You received this message because you are subscribed to the Google Groups DIYbio group. To post to this group, send email to diybio@googlegroups.com. To unsubscribe from this group, send email to diybio+unsubscribe@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/diybio?hl=en
Learn more at www.diybio.org
---
You received this message because you are subscribed to the Google Groups "DIYbio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diybio+unsubscribe@googlegroups.com.
To post to this group, send email to diybio@googlegroups.com.
Visit this group at http://groups.google.com/group/diybio.
To view this discussion on the web visit https://groups.google.com/d/msgid/diybio/538A1F14.6050508%40industromatic.com.
For more options, visit https://groups.google.com/d/optout.