-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a monthly invoicing process for personnel and cloud costs #355
Comments
Update: converging on a few documents@colliand and I met with the CS&S team today to go through the invoicing process that we are shooting for. Here are a few highlights:
|
I think we need to cross-reference any work happening in our infra around this project/need. |
I've added an extra task here to finish a one-time recoup of our cloud costs from 2022. I've also included a bunch of data about what our actual costs were, and which projects they belong to: |
Note that the Engineering team is setting Billing as a Q4 priority, but they need guidance from this team about what needs implementation. See their tracking issue below and please provide feedback if you can: |
We are having a dedicated meeting with @jmunroe and @yuvipanda later today to get into the specifics of what would be needed and how to accomplish it. |
I'm pasting in an update that @yuvipanda gave in Slack that I think was regarding this meeting:
It doesn't look like @colliand is in-the-loop on any of those steps. Can somebody confirm who is the one responsible for driving this effort forward, and re-assign this issue to that person so that we have clarity? |
There are several pieces from the summary you pasted above that will be run in parallel... and those tasks are already assigned to people. This is shared work so it is not clear to me if there is just one person to be assigned. Temporarily I have assigned this to myself as a representative of the group pushing this forward. |
Agreed that we need to divide and conquer the individual tasks, but we need to have one person responsible for the effort as a whole, and making sure we are making progress in all of these individual places. E.g.I think if we have a "tracking issue" that has lots of sub-issues, the person assigned to the tracking issue should be the one coordinating and delegating, and ultimately is responsible for the whole effort being completed. |
In general, I agree with this point of view! Although I think this idea needs an iteration (most likely in the future, not now) where there are groups of people to be assigned instead of one person and "the group" is responsible for pushing things forward. But, GitHub is bad at the time to have grouped assignations AND we still need sole assignations given our size and current state of the organization. |
OK, I have updated #555 (comment) with the next steps on @jmunroe's hands. I also created placeholder issues inheriting from the goal billing issue which @yuvipanda will further specify from the technical perspective. FInally, I tried to connect those issues with pre-existing discussions. |
Closing this one as mostly completedWe've documented the process for invoicing ongoing contracts in a few PRs: And we're tracking the improvements to cloud billing infrastructure here: So I'll close this one as completed and we can focus our efforts on new issues that track iterations on this work |
Context
We currently define our invoicing process here. In brief, we must manually send an email to every community that we wish to invoice every month. When they confirm that the service has been delivered, we send that to CS&S and they can send an invoice.
By having this manual step each month, we create more manual toil that we need to manage and carry out. This makes our invoicing process more complicated than it needs to be, given that most communities likely just want a monthly invoice (if we expect repeating business), not a confirmation email first.
Proposal
We should either:
This would reduce the number of manual steps associated with billing/sales, which would make the service more scalable and less prone to error.
Implementation guide and constraints
We'll likely need to collaborate directly with CS&S on this, to see if they are legally restricted by their accounting practices in someway.
Updates and ongoing work
The text was updated successfully, but these errors were encountered: