Define the "something else" board(s), process(es) and structure

[aprilmj]

What is this and why is it important?

In our March Initiatives board retrospective and planning conversations, we realized we needed a way to prioritize and track task-level work that isn't already in the Engineering or Partnerships delivery/sprint boards.

There are two types of work that we don't fully track today: "Operational" (organization-wide, funding, People or Product) and "Upstream" (typically a mix of Partnerships and Engineering leadership and consulting on upstream projects, today tracked as issues mostly by @yuvipanda).

Assuming we follow the general pattern discussed in #816 (all non-reactive work is defined in the Initiatives Board and planned for a sprint within a team sprint board), these two types of work likely need two different processes.

More detail in the issue/task cards for each board:

Tasks

Beta Give feedback

1. Gather information about "something else" types of work
2. Consult with team members about how they plan and track "something else" work today
3. Feedback on draft proposal for "Operations" board #819
   +0
   

   
4. Feedback on draft proposal for "Upstream" work #820
   +0
   

   

[colliand]

I have had some recent exchanges with Maryam Vareth re: JupyterHealth that overlap with this issue. FYI @aprilmj and @jmunroe.

Maryam is serving as the Project Manager for the JupyterHealth project. She reports to Fernando Pérez who is a Co-PI (with Ida Sim) for this project. The JupyterHealth project has several partner organizations involved:

• U.C. Berkeley
• UCSF
• Simula
• a team of metabolic health data scientists at Duke University
• a team with The Commons Project who built the Common Health Mobile App
• 2i2c

Maryam brings this diverse group of partners together in meetings and is charged with organizing delivery systems to guide the team to build software systems leading to data products that will help health care providers give better health service to patients.

Maryam is new to project management. She contacted me seeking guidance on how to implement an effective delivery system for this project. I laughed pretty hard when she asked....! I shared an overview of the systems we are building for the 2i2c team, explained that coders often find it convenient to work inside GitHub, and suggested that she consider using a Project Board in GitHub. I also explained to Maryam that 2i2c's transformation toward an improved delivery system was being driven by @haroldcampbell and @aprilmj.

I discussed this with @jmunroe. If/when 2i2c develops a robust (and measurably good!) delivery system, I imagine that there will be ways for 2i2c's skill to be transmitted into other projects. I perceive that many of our collaborating partners would like 2i2c to provide systems that push collaborative projects forward.