jonny commented

Owner

One of the most frustrating things about my current work is that I feel like I am working alone on something that no one else in the lab cares about/uses/etc. I also think it is both frustrating and a missed opportunity to have labor duplication in a setting as small as a lab because there is missing visibility and coordination between projects. I have also felt discouraged in my current lab that I will put substantial work into leading workshops, developing protocols and practices, and training my labmates on methods for coordinating work only to have it be for nothing because there is no labwide leadership reinforcing it. It seems like you are on the same page of trying to find the balance between micromanagement and disorganization/lack of coordination, and that's how I see the problem too - one of finding a coordination style that works for everyone, rather than mandating the minutiae of how to work.

From what you've described and the conversations I had with the lab during my visit, it seems like there is a relatively clear macro-project that the lab is working on where all the pieces fit together, and I'd like to work on building infrastructure for the lab. This would be both for the benefit of our work, but also as part of my general research into technologies and techniques of organization.

Public/Private Wiki

The project is already organized in a set of public wikis which rocks. I think we can extend that:

I'd like to build out the miniscope wiki to use the sort of semantic organization system that the autopilot wiki uses, and either consolidate or else otherwise integrate it with the other projects like this one for the miniscope v4. I see the value in organizing them separately, linking the docs to the repo that has the cad and software makes sense, so rather than moving everything to one system, we could figure out a way to make them interoperable and clearly indexed. Interoperability between mediawiki and markdown wikis like those used on github is a point of general need, and we might consider this as something we could do in collaboration with the broader wiki community.
I think we can also do this internally, using a private wiki to organize the "contextual knowledge" of our separate projects in a very freeform, but nonetheless discoverable medium. I have written about the different axes of need for information organization, and wikis hit sweet spots across a bunch of them, and especially if our public infrastructure is also a wiki would pay off in not having to do a lot of context switching to make things public. I've done this in a few contexts (labwork, social organizing, co-operative livving, labor organizing) and have seen it totally transform how organizations work for the better. It's not a trivial thing though! as it requires active investment, setting of norms, creating systems that support work rather than making extra documentation busywork, etc.
I've also been working on building bridges between other mediums and wikis, in particular for a workshop I'm facilitating next month I've been building a bot to be able to crosspost information from multiple mediums (in our case, twitter and discord) to a wiki, so one can have conversations on eg. slack and then be able to keep track of them by using [[wikilinks]] and [[semantic::wikilinks]] inline with the chat. I plan to write this up as a short conference paper with how it works in this workshop, and we could continue that work!

Interoperability

I think it would be cool to experiment with a system for designing for interoperability between different projects from the start. To me, this looks like (in addition to plenty of other things) a combination of information organizing systems like wikis described above and an integrating software framework for coordinating their use together. Related to #4, I'd like to work with you and the lab to build one! We could use Autopilot for this, though, as I was saying during my visit, it needs substantial rearchitecting, so this might look more like taking lessons learned from it and building a non-backwards compatible "v2."

More generally, I think this would look like charting out a course for lab framework code where common operations are shared rather than local to a project, and then individual projects inherit from it. This would require a decent amount of coordination, but I think it would pay off longterm to be able to start a new project with a lot of "code in hand" because we have laid the groundwork for a cumulative body of code and information. I think if we were active about this process the documenting the process would be a pretty natural outcome, and it might be useful for the broader toolbuilding community for us to be a point of experimentation in how to organize work at a lab level, of which there is relatively little canonical wisdom as far as I can tell!

One of the most frustrating things about my current work is that I feel like I am working alone on something that no one else in the lab cares about/uses/etc. I also think it is both frustrating and a missed opportunity to have labor duplication in a setting as small as a lab because there is missing visibility and coordination between projects. I have also felt discouraged in my current lab that I will put substantial work into leading workshops, developing protocols and practices, and training my labmates on methods for coordinating work only to have it be for nothing because there is no labwide leadership reinforcing it. It seems like you are on the same page of trying to find the balance between micromanagement and disorganization/lack of coordination, and that's how I see the problem too - one of finding a coordination style that works for everyone, rather than mandating the minutiae of how to work. From what you've described and the conversations I had with the lab during my visit, it seems like there is a relatively clear macro-project that the lab is working on where all the pieces fit together, and I'd like to work on building infrastructure for the lab. This would be both for the benefit of our work, but also as part of my general research into technologies and techniques of organization. # Public/Private Wiki The project is already organized in a set of public [wikis](http://miniscope.org/index.php/Main_Page) which rocks. I think we can extend that: - I'd like to build out the miniscope wiki to use the sort of semantic organization system that the autopilot wiki uses, and either consolidate or else otherwise integrate it with the other projects like this one for the [miniscope v4](https://github.com/Aharoni-Lab/Miniscope-DAQ-QT-Software/wiki). I see the value in organizing them separately, linking the docs to the repo that has the cad and software makes sense, so rather than moving everything to one system, we could figure out a way to make them interoperable and clearly indexed. Interoperability between mediawiki and markdown wikis like those used on github is a point of general need, and we might consider this as something we could do in collaboration with the broader wiki community. - I think we can also do this internally, using a private wiki to organize the "contextual knowledge" of our separate projects in a very freeform, but nonetheless discoverable medium. I [have written](https://jon-e.net/infrastructure/#shared-knowledge) about the different axes of need for information organization, and wikis hit sweet spots across a bunch of them, and especially if our public infrastructure is also a wiki would pay off in not having to do a lot of context switching to make things public. I've done this in a few contexts (labwork, social organizing, co-operative livving, labor organizing) and have seen it totally transform how organizations work for the better. It's not a trivial thing though! as it requires active investment, setting of norms, creating systems that support work rather than making extra documentation busywork, etc. - I've also been working on building bridges between other mediums and wikis, in particular for a workshop I'm facilitating next month I've been building a bot to be able to crosspost information from multiple mediums (in our case, twitter and discord) to a wiki, so one can have conversations on eg. slack and then be able to keep track of them by using `[[wikilinks]]` and `[[semantic::wikilinks]]` inline with the chat. I plan to write this up as a short conference paper with how it works in this workshop, and we could continue that work! # Interoperability I think it would be cool to experiment with a system for designing for interoperability between different projects from the start. To me, this looks like (in addition to plenty of other things) a combination of information organizing systems like wikis described above and an integrating software framework for coordinating their use together. Related to https://git.jon-e.net/work/postdoc/issues/4, I'd like to work with you and the lab to build one! We could use Autopilot for this, though, as I was saying during my visit, it needs substantial rearchitecting, so this might look more like taking lessons learned from it and building a non-backwards compatible "v2." More generally, I think this would look like charting out a course for lab framework code where common operations are shared rather than local to a project, and then individual projects inherit from it. This would require a decent amount of coordination, but I think it would pay off longterm to be able to start a new project with a lot of "code in hand" because we have laid the groundwork for a cumulative body of code and information. I think if we were active about this process the documenting the process would be a pretty natural outcome, and it might be useful for the broader toolbuilding community for us to be a point of experimentation in how to organize work at a lab level, of which there is relatively little canonical wisdom as far as I can tell!

jonny added this to the Project Details project 2022-10-10 23:45:57 +00:00

jonny added the

proposal

label 2022-10-10 23:46:31 +00:00

jonny added a new dependency 2022-10-11 02:25:10 +00:00

#2 Contract

jonny removed a dependency 2022-10-11 02:25:30 +00:00

#2 Contract

daharoni commented

2022-10-11 04:36:07 +00:00

Collaborator

This is a huge YES for me!

We will need to discuss what this really would look like, how big we want to push it initially, if we want to bring other local labs (or other Miniscope labs) on board from the start, and so on.

As I mentioned in my response on your Autopilot topic, I am really interested in potentially throwing away all of our past work/infrastructure around the Miniscope project (and lab/project management in general) and start from scratch. I'm not sure exactly what this would look like so let's chat more about it and toss some ideas around.

This is a huge YES for me! We will need to discuss what this really would look like, how big we want to push it initially, if we want to bring other local labs (or other Miniscope labs) on board from the start, and so on. As I mentioned in my response on your Autopilot topic, I am really interested in potentially throwing away all of our past work/infrastructure around the Miniscope project (and lab/project management in general) and start from scratch. I'm not sure exactly what this would look like so let's chat more about it and toss some ideas around.

Lab Infrastructure/Intra-Lab Coordination #5

Public/Private Wiki

Interoperability