New policy proposal: Ambassador Reimbursement Requests (ARRs)

Hi Mindshare folks. Earlier this week, I made a first draft of new policy for the Mindshare Committee about how we should reimburse Ambassadors who benefit from funding to be advocates for Fedora in the field. The process right now is not clear, so this is my attempt to add more structure and manage expectations when it comes to reimbursements in Fedora. I’ve called these Ambassador Reimbursement Requests, or ARRs[1].

Some of you may have been reimbursed by Fedora before COVID-19 and some of you may have never received reimbursement by Fedora. This makes for a great reviewer group to read the proposed process and understand whether it is clear and makes sense:

Feedback is welcome here. Reimbursements are a long-time pain point. This is one way I hope they can become less terrible, and also provide more transparency in the process too.

  1. Why ARRs? We want smooth and expedited reimbursements. We don’t want someone to go “arrrrrrrr!” while trying to be reimbursed by Fedora. :slightly_smiling_face: ↩︎


I don’t have any comments on the process itself but I do have some comments on the document.

In no particular order:

  • It isn’t clear to me at what point in the process you need to create/submit a BEAR ticket.
  • Are there three separate tickets/issues/forms that need be created? Mindshare Ticket, ARR and BEAR?
  • The process and checklist sections have way too much overlap. The checklist is written in a way that is much more clear. It doesn’t feel like the process section adds much clarity over what is in the checklist. Is it possible to combine these? If not, I would recommend removing detail in the process section since it is mostly covered by the checklist.
  • It is called a reimbursement request but most of the steps happen prior to the expense being incurred. It feels strange to me to call the document that you use to approve the future event/expenditure a reimbursement request.

Just my thoughts as someone who is totally unfamiliar with it reading it for the first time.

Hey @dalto, thanks for taking a look.

Good point. A BEAR ticket should follow an approval on a public Mindshare Committee ticket. I’ll update the doc.

Yes, it is three forms in most cases. Does it feel too much? One challenge is that different kinds of information are needed at different stages, and some of the information could be sensitive (e.g. financial records).

One thing I am 100% sure of that there must be a public, open process where someone could request funding. The decisions made on the ticket should be deliberated publicly with a view of the Fedora budget. After that though, there is room to deviate.

In the current method, the ARR ticket is private and only shared with the Mindshare Committee. Financial records will be shared there. The BEAR ticket is also private but only shared with the Fedora Council. No financial records are stored in the BEAR ticket but there is personal information like employer and job title, and what their travel itinerary is.

I wonder what a better way to structure this would be.

Something about the process is important to include. The key detail is that there are three checks that must be cleared in order for a reimbursement to work out. I want it to be very clear that anything that does not pass the three checks becomes extremely difficult or impossible to reimburse. For example, I’d want someone to know that before booking a $1500.00 USD flight with the assumption that Fedora will cover the costs.

Also, I could move the checklist above the Process section, if that would be more clear.

Naming things is hard. :slightly_smiling_face: I’m definitely open to better names though.

I guess I have described a few things here, including a public event proposal ticket, the private Ambassador Reimbursement Request ticket, and the BEAR ticket. Perhaps this policy could be reframed as “Event Reimbursement Policy” and then the public Mindshare ticket, the ARR, and the BEAR ticket would be sub-components of the policy.

Would that make more sense? Or is it only making things more complicated? :thinking:

I won’t say it is too much but it definitely feels like a lot. Especially if the cost isn’t that great.

Is it possible to combine these two or is the BEAR a RH document that is out of our control?

I think you can simply say that. All the information about the process and process gating is too repetitive. Instead focusing so much on gates/phases why not use a more plain language approach.

If I understand it there are few main things:

  • Initial event proposal - Mindshare ticket and initial approval
  • Event planning - BEAR and ARR(I still think this is a strange name)
  • The event itself - Documentation, pictures, etc
  • Reimbursement - Submission of final materials and final approval

This would also help people understand how everything fits into the real world timeline.

It seems more like an “Ambassador event approval and reimbursement policy” or something along those lines.

Lastly, the thing currently called a checklist doesn’t feel like a checklist to me, it feels more like a process.

Generally the cost is when travel expenses are involved (e.g. airfare and a hotel booking). It could also be a local release party, although a BEAR ticket may not be required for all release parties.

It comes down on data privacy and need-to-know access. There could a single, private issue where all sensitive information is kept. The current setup is that some data flows to the Fedora Council while other data flows to the Mindshare Committee. Except for people with membership in both groups, one person cannot see the sensitive data in the other repo.

However, the separation is arbitrary and a decision I made. I don’t have a legal instruction to separate them, but I was erring to keep a need-to-know basis for certain types of data. It limits exposure to potentially sensitive data if someone’s account was compromised or exploited.

Good call. So, I could condense the process and gating system section into the opening paragraph. Then, the only lengthy section of the doc is the “checklist” (which I would rename to process instead).

This is accurate. I could lift this language into the opening paragraph instead. What do you think?

This is true, although the GitLab repo name has a character limit. I was trying to come up with something catchy that would also fit into the title field.

1 Like

How large are both these groups? Is this providing significant benefit?

If it is important, would it be possible to have a single form that shares only the relevant data with each group?

I think that would read more clearly. :slight_smile:

The Council currently has nine members and the Mindshare Committee has eight members. The separation of data only comes toward the need-to-know basis.

I could set up a LimeSurvey form that only goes to me, and then I could open tickets in the appropriate places. The only part I don’t like is that the person whom I would open the ticket on behalf of will not get emails with updates or comments about their request. I’m not sure whether I can “add” an account to a private GitLab issue.

1 Like

That lessens the workload of many people and puts it 100% on you. That seems bad. :slight_smile:

If there is no easy way to avoid 3 forms for each event it isn’t the end of the world.

Heheh true… I do recognize that three forms is unwieldy though. Fortunately, each of these steps usually happen in intervals. It is not common that you are filing all three tickets/forms at once.


Is it worth asking if outsourcing to something like Expensify might help with the complexity? I imagine the fact that it’s reimbursements for people who aren’t employees or contract vendors makes it especially awkward.