We are creating a powerful and flexible TEER measurement device that will affordably enable new experiments to be conducted in a user friendly way.
Welcome everyone! My name is Michael Anderson (I sometimes use MD Anderson as my name online as Michael Anderson is wayyy too common of a name). I am currently a PhD level staff scientist in microscopy core at Boston Children’s Hospital. My background is in physics and microscopy/optics.
This Flexi-TEER project has been a side project of mine for the past couple years. For the first year it was just an idea that TEER seems simple and it shouldn’t be very hard to make a new device to enable us to conduct an experiment we wanted to do. The second year was realizing that it is more difficult and nuanced than it seemed at first. We also realized that this device has a ton of potential, much more than just our individual lab. So we decided to make it Open-Source in hopes that this project could be expanded on and really have a large impact. We have made massive progress though and I think we are very close to having an actual functioning device.
Point people to your Code of Conduct for the project, and require users to read it before they go any further (Need to make Code of Conduct)
Below is a breakdown of aspects of the project and what we are currently working on
List Communication Channels: (Jira, Slack)
Tell readers how to submit changes: This is the process for adding your work or changes to the repository or collection of ongoing work What should this be? No good ideas.
You can report any bugs to our github Tell readers how to report a bug: Ask your contributors to stay on the lookout for can any potential issue that might cause problems for the project. These could be problems in code , content omissions or copy errors, or any issues with the functionality or design of your project. Basically, by asking users to report bugs, you’re asking for feedback on work that’s been done. (dont know quite how to do this yet).
Most projects invite all contributors to tell the project lead about bugs, so “debugging” or fixing problems happens quickly and with the input of the community. Take a look at Atom’s example for how to teach people to report bugs to your project.
Tell developers about your recognition model - Remember, you need to acknowledge value of the time and work your volunteers give your project. Here, provide a pre-emptive “thank you” for interest contributing.
This is an important aspect, especially so in the open-source space. We recognize you in several different ways:
List any recognition contributors might receive for participating in your project. You can also outline how contributors can “level up” to become project maintainers (a certain number of bugs resolved, a certain number of changes or contributions successfully submitted to the project).
You can leave this blank for now, and fill it in later. Let developers know where to go for help - provide clear contact info, and outline the process for getting in touch, for anyone with questions.