Organization of the DRiP GitHub org

[abranczyk]

The DRiP project has two separate aspects:

1. Developing the framework/workflow/resources for doing research in public
2. Using the framework/workflow/resources for doing research in public

I propose that everything related to developing the framework/workflow/resources be kept in the meta repo, where we flesh out the ideas within the repo and we keep track of tasks related to developing the framework/workflow/resources as issues and on the project board related to this repo.

For using the framework/workflow/resources to do research, I propose that early stages of research projects (leads, open problem outlines) get captured in the project board on the research-projects-overview repo.

Then, when a project gets to a stage where people have actually started working on it, it would get its own repo, which will be created from a template repo for research projects.

[abranczyk]

Although, it's not clear to me whether we even need a research-projects-overview repo, or whether we can get away with just having a project board in the org that isn't associated with a repo.

The main thing I would like to ensure is that when someone adds a lead or a project outline, this is recorded for posterity so that they can get credit for their contribution in the future if this turns into a viable research project.

Any thoughts?

[Christophe-pere]

It reminds me of when I used the Kanban structure with my teams. I was using Kanban to follow projects where people could join to participate. And a kanban for the project's tasks, like every contribution/task was assigned to someone.
We can see it as two boards:

• one at the level project to see which one is in progress
• another board for tasks with colour or icons related to a specific project.

The teams were very active because people could choose the project and task in the project. It was better for motivation. Something similar can be envisioned to follow the different research projects.

For example, tags could be added if mentorship, supervisor, etc., are needed for a project.

[abranczyk]

Yes exactly. I think the kanban board is a great way for distributed teams to work asynchronously.

[Christophe-pere]

Building templates to propose ideas, projects or collaborations could also be interesting. In Markdown, it's easy and reusable.

[abranczyk]

Yes, I agree about the templates