Create a system for community / partnerships to define and track their efforts #510
Comments
choldgraf
added
Partnerships
|
I spoke about this with @jmunroe a bit, our goal will be to propose a system for tracking work in @2i2c-org/partnerships-and-community-guidance within a week. Adding that to our team backlog check-in date. |
|
While there are "task management" software services like Todoist looks ok for personal task tracking, I'm not sure that it has the project management features that would work for team coordination. Since 2i2c is already a major user of GitHub issues/projects, could we also run our partnerships/community task tracking through that service (using private repos as needed)? 2i2c has prioritized a "single source of truth" and building out a system on another platform. If there were some specific Project Management feature (e.g. Gannt charts that GitHub does not offer, then there are add-ons (like ZenHub ) we could consider. I think using Todoist or a similar platform is only an option if it has a tight integration with GitHub. |
Proposal: Use GitHub for tracking these effortsI haven't seen any proposals from the @2i2c-org/partnerships-and-community-guidance team and we are well-past our check-in date for this, so I'd like to propose a path forward here. We need to agree on this system quickly so that we can define a source of truth for how we'd like to organize ourselves. I think that the @2i2c-org/partnerships-and-community-guidance team should use GitHub issues to track its efforts. This includes development projects like "building a leads pipeline" as well as ongoing efforts like tracking the status of an individual lead. We can accomplish this with a combination of issues (for content) and GitHub project boards (for tracking status and other metadata about issues). To begin, I suggest that we:
If we need to keep track of extra assets for communities, we should do so with folders in our shared Google Drive that have unique IDs that can be attached to issues, so that we have a source of truth for "where is the information about contract/collaboration X?". Rationale: Using GitHub issues will allow us to more-easily draw connections between our @2i2c-org/partnerships-and-community-guidance and our engineering team. While these are two different functional areas of 2i2c, they are effectively on the same "product team" for our managed hubs service. For this reason I think that using two different systems for tracking work will lead to information silos - we will pay a coordination penalty for this, and it will also be harder for us to hold one another accountable for getting things done. This will become a bigger issue as we continue to "tighten up" our leads -> sales -> hub -> support -> development process. This proposal also seems very similar to what @jmunroe suggested above (apologies if you were making a specific proposal there and I didn't realize it) Feedback please@colliand and @jmunroe please provide your thoughts on this proposal within 48 hours, or make an alternative proposal for how you'd like to organize your efforts. I also welcome feedback from others on the team but I think @2i2c-org/partnerships-and-community-guidance is the group we need buy-in from since they'll be the ones carrying out this proposal. I'll update our checkpoint date to follow up in a couple of days. |
|
Community and Partnerships have been discussing in our last few meetings. I forgotten we had created this specific issue and should have linked our notes back to here. GitHub issues are indeed where we want to track all our product/community related workflow. Implementation of the 'Community and Partnerships Project Dashboard" is being tracked in https://github.com/2i2c-org/leads/issues/94 I believe there are multiple, yet clearly related, workflows in play here. One is the status of an individual "hub deployment". This requires visibility between engineering and parterships. Based on interactions between the @2i2c-org/partnerships-and-community-guidance team and the community partner, the needs for a hub are scoped with input from engineering. The actual deployment is done by engineer once all of the required information is available. Hubs should normally have a quote/contract in place that will be linked to a community partner that will provide payment. I believe that hubs should always have a "stop date" associated with them. When we are getting close ("close" needs definition) to this stop date, an automatic trigger should prompt @2i2c-org/partnerships-and-community-guidance to investigate renewal of a contract or clarify with the community partner that a hub should be shutdown. This is also important for hubs which are created in anticipation of an upcoming contract. If no agreement has been reach by this "stop date", we can give ourselves a chance to follow up with the community partner and then shut down the hub. As a workflow, a 'hub' needs to move from one state to another. Possible states: 'Ready to be provisioned', 'Running', 'Failing', 'Ready to be decommisioned', 'Stopped', 'Terminated' (is it possible we could borrow the language k8s uses for pods for these stages?) This "hub" workflow should have specific time boxing of when the hub is being provisioned, when it actively being operated, when it is scheduled for decommission. Even for hubs which are internal to 2i2c (so we are our own client), I think we can set them up this way so we don't create any cloud resources and then let them run without an unspecified end date. There is another similiar, yet distinct, workflow involving the "contract" for a business relationship between 2i2c and its community partners. This pipeline requires visibility between 2i2c and CS&S. The contracts and quotes related to deployments need to be tracked here and are key to setting up accurate billing/invoicing. Google Drive is where 'documents' for these are shared. The workflow is different because I can imagine a sales interaction that might need to go on for a while well before it is appropriate for a "hub" to be provisioned. And even after hub has been decomissioned, we may want to start up a new relationship with that community partner in the future (e.g, Hackweeks). A single community partner may choose to deploy several different hubs under the same contract or it could be different contracts. I think we need to break the one-to-one mapping between a "hub" and a "community partner" (even if that is the most common situation). This "contract" workflow is tied to the life-cycle of the business relationship: "Prospect", "Negotiation", "Active", "Ending", "Completed" are potential status labels. A business relationships does not itself need to have a hub related at all. It may be reasonable to capture "Grants" in this same workflow. Like the "hubs" workflows, "contracts" should also have an associated time box of start and stop so that we can automatically trigger renewal and intervention well before the "end date" is reached. So, my proposal is to have a unique issue for each "hub" and each "contract" we have that moves through these states. Individual tasks that need to be completed by either @2i2c-org/tech-team or @2i2c-org/partnerships-and-community-guidance can be associated with these issues. For example, there may be an engineered support issues that could reference the "hub" issue for tracking. Or a community led onboarding event that is associated with a "contract". |
|
This sounds great, thanks for the extra explanation @jmunroe . It sounds like there are basically three kinds of things to track here:
It feels to me that number 1 is the most realistic / important to complete in the short term, because we can use it to track progress and major efforts on the others. This is what my proposal above was focused on. Agreed that we still need to figure out the right system for items 2-4. Does that make sense to you? And if so, can you make a pull request to the team compass to encode how you'd like to track development efforts within the @2i2c-org/partnerships-and-community-guidance part of 2i2c? Then we can encode it in our team compass and start iterating from there. |
|
@jmunroe and @colliand can you please update the top comment with your intentions for how to resolve this issue? I see that the dashboard issue exists as noted above: Is that dashboard going to contain all of the information about what Partnerships/Community is up to? Or is it only part of it? I would like somebody to make a clear and concise plan of action in the top comment so that we know how to resolve this one, and so we can put a checkpoint date on it. I appreciate that we want to have the "right" system here, but this issue has been open for more than a month now. I need @jmunroe and @colliand to just pick a system and start using it ASAP, at the very least for defining the development efforts you wish to move forward - those are the most important things to track right now. |
|
This issue refers to a system track what Community and Partnerships is managing. This has now been implemented in a new Community and Partnerships Project Board. The structure of this new project board is based off the existing engineering project board Team Backlog and follows the same overall structure and organization. We also are intending on creating a third "organizational" board that captures issues that cross-cut multiple functional areas of 2i2c or track larger projects that require visibility across 2i2c. I think it is ok GitHub issues can live in multiple project boards (especially if they are issues that need visibility by both Partnerhips and Engineering). We should also write a query that identifies any GitHub issue (across all repos) that is not captured in one of these three project boards. If there is an issue that is "homeless" that we should consider redefining the issue so it falls within (at least) one of the functional areas of 2i2c. If the issue is really under any functional area of 2i2c, they perhaps that is evidence it should be closed. |
|
The issue refers to another kind of "dashboard" that is attempting to visualize our contracts, leads, hubs, and external commitments across 2i2c. It requires information from both CS&S and 2i2c and so can not live solely as a GitHub project board. I will update the top comment to make it clear that there are two distinct "dashboards" being proposed here. |
I agree.
💯 |
Question: what is our "work in progress"?I've been trying to use this project board to understand where are the current priorities of the @2i2c-org/partnerships-and-community-guidance team, but I'm having a hard time understanding this. Currently there's an However, this has a lot of different issues in it. This makes it hard to understand what we are actively working on right now, vs. what we theoretically want to be working on over the next few weeks. The product/engineering team solves this with Sprints, but we don't have this concept for partnerships/community. Can @jmunroe or @colliand make a proposal for how they'd like to track "immediate-term efforts along with a self-imposed deadlines to complete them"? |
Context
Currently our team uses this GitHub Project to track all of the "in progress" efforts for our team. @damianavila helps to steward and route work items to relevant people for the @2i2c-org/tech-team .
I've had a few conversations with @2i2c-org/partnerships-and-community-guidance and it sounds like they may prefer to use a different system for tracking their work than GitHub Projects.
It is crucial that our teams have a "source of truth" to coordinate with one another asynchronously. Without it, we do not know what work is in-progress and how much capacity we have.
Proposal
The @2i2c-org/partnerships-and-community-guidance team should agree upon a system for tracking their priorities as well as their in-progress work. I'm fine with whatever system they feel is best for themselves (and any other people that work in these groups in the future). I think that such a system should be the "source of truth" for the following questions:
Updates and actions
The text was updated successfully, but these errors were encountered: