Reps/SOPs/Budget: Difference between revisions

From MozillaWiki
< Reps‎ | SOPs
Jump to navigation Jump to search
(Warning added)
 
(140 intermediate revisions by 11 users not shown)
Line 1: Line 1:
'''Budget request SOP for Mozilla Reps'''
{{Warning |1= With effect from 1st September 2023, the Mozilla Reps program was closed and activities ended.|title= With effect from 1st September 2023, the Mozilla Reps program was closed and activities ended.}}


== Overview ==
{{Remonav}}


In order to effectively support Mozilla Rep activities/projects around the world, a budget request SOP exists to evaluate, approve budget requests submitted by Mozilla Reps and efficiently disburse funds. 
__TOC__


This SOP outlines:
= Overview =


• what selection criteria should be used to assess and approve a specific budget request<br>
In order to effectively support Mozilla Rep activities/projects around the world, a budget request SOP exists to evaluate, approve budget requests submitted by Mozilla Reps and efficiently disburse funds.
• who approves the budget requests<br>
• what the different review stages of approval budget requests go through<br>
• how funds are disbursed<br>
• what follow-up strategy is employed to measure the success/failure of a funded activity/project<br>


This SOP outlines/answers the following questions:


== Assessment Criteria ==
==What questions should I ask myself before requesting a budget==
*Opening a bug can be a lot of work. Make sure that you have answered all the questions mentioned on the assessment criteria before you open your bug. If you’re not sure about a question please don’t hesitate to reach out to your mentor. He/She will be able to help you plan your event.
==What things do I have to check to submit a budget==
*So what is the information that I need to add in my bug and my event page so my bug can be ready for review? On the budget guidelines section you will be able to find a small checklist with the necessary things, a small blogpost from Regnard and a table with all the things that can be approved in the Program


a) Main focus areas<br>
==How does the process work once I submitted the budget?==
*The Reps program follows a double approval procedure. Check the [[ReMo/SOPs/Budget/Process|procedure page]] for more technical details.


It is essential that clear criteria of relevance and success be established so that the ReMo Council can properly assess budget requests. It is important to consider the following questions when evaluating a budget request:
==What should I do to get reimbursed before and after the event?==
*So you got approval but you’re unsure on how you will receive the funds. Check the Disbursement of Funds and  Follow up.


• How will the event or activity promote Mozilla’s mission?<br>
==Can we use left over budget from the other event?==
• Does this opportunity represent a relatively small level of financial support that will have a large impact on others in the Mozilla community?<br>
*The Reps should file a new budget request in order to use the budget even if s/he already have the budget. Reps are not allowed to use the budget without advance approval from the review team.
• Does the project empower other members of the community?<br>
• How will Mozilla's financial support impact others both in Mozilla and in the larger user-community? Is the investment in the community being successfully leveraged?<br>
• How measurable is the success of the event/activity and how easy is the follow-up ?<br>
b) Disqualification of Budget Requests<br>


Budget requests received less than 3 weeks before the targeted launch date of the event/activity in question will automatically be rejected (exceptions can be made but only with council approval). This 3-week “buffer” guarantees that each budget request undergoes the same thorough selection process.<br>
= Assessment Criteria =


Futhermore, the ReMo budget request SOP is open ONLY to Mozilla Reps. A person who is not a Mozilla Rep requesting a budget via the ReMo Budget Request SOP is automatically rejected from the procedure.
The Assessment Criteria for Budget Requests can be found on [[ReMo/SOPs/Budget/Assessment-Criteria]].


=== Questions to ask yourself when reviewing a budget ===
== Disqualification of Budget Requests ==


See full list of recommended questions '''[[ReMo/SOPs/Budget/Questions|here]]'''.
Budget requests received less than 3 weeks before the targeted launch date of the event/activity in question will automatically be rejected (exceptions can be made but only with council approval).


== Budget Request Form ==
This 3-week “buffer” guarantees that each budget request undergoes the same thorough selection process.


To request a budget, the following [https://bugzilla.mozilla.org/form.reps.budget budget request form] needs to be completed and submitted.
<div style="padding: 1em; background-color: rgb(255, 242, 204); border-width: 1px; border-color: rgb(255, 217, 102); border-style: solid;">
'''Budgets that don't reply to the basic information asked in this SOP will be moved back to mentor review.'''


As an additional resource, it would be recommended for Reps to read [http://weboplex.com/post/34386033488/the-quick-guide-to-writing-budget-requests-for-mozilla The Quick Guide to Writing Budget Requests for Mozilla Reps].
Basic information to be provided:


== Three-phased Screening/Selection/Approval Process ==
<ol>
<li>Which functional area goals is this supporting and how?</li>
<li>What are the event goals? What's success for this event? How are you going to measure it?</li>
<li>Why this budget is needed for the success of the event?</li>
<li>Detailed agenda (what are we doing, activities to support the event goals)</li>
<li>[https://docs.google.com/spreadsheets/u/1/d/12FDeW3Qd5M2Mfpr8e7edCfXcUtqHP3lh3xwSln8w4G4/edit?usp=drive_web Budget breakdown] attached to the bug once created (who are we covering?)</li>
<li>Are there "optional" costs not needed for the success of the event? Which ones? What the minimum viable budget?</li>
</ol>


The process of bugdet requests is made up of three distinct phases:
</div>


1) preliminary screening made by the Rep's mentor<br>
{{admon/important |Receipts from previous budget requests| Make sure that you have attached all of your receipts at your previous budget requests. Reps that haven't submitted previous receipts will not be able to request budget for their new events.}}
2) "filtering" made by Budget Task Force and approves/rejects budget requests <$500 USD<br>
3) the ReMo Council approves or rejects budget requests >$500 USD<br>


=== Peliminary Screening ===
=Budget Guidelines=
==== Requesting Review using flags ====
==Budget Checklist==
When a Rep makes a budget request, (s)he must request that their mentor review the bug. The mentor is responsible for ensuring that the budget detailed in the request is appropriate for review. It is up to the mentor to decide when the budget request ready to be reviewed by the Budget Task Force.
Here is a short checklist with all the things you need to have into your budget request before submitting it:
*number of attendees expected at the event
*venue
*date
*description and purpose of the event
*event schedule / agenda
*list of other mozillians who are going to participate
*target audience
*3 success metrics
*[https://docs.google.com/spreadsheets/u/1/d/12FDeW3Qd5M2Mfpr8e7edCfXcUtqHP3lh3xwSln8w4G4/edit?usp=drive_web clear break down of expenses] (form made by Michael Kohler based on the template the Filipino community is using)


To request review, the Rep needs to use the flag option located under the CC list. The Rep '''must set the remo-review flag to ?''' and then it will give you a field to enter your mentor's bugmail address.
As an additional resource, it would be recommended for Reps to read '''[http://weboplex.com/post/34386033488/the-quick-guide-to-writing-budget-requests-for-mozilla The Quick Guide to Writing Budget Requests for Mozilla Reps]'''.


==== Screening by the mentor ====
{{admon/note|Filing a Budget Request|To request a budget, get in touch with a [[ReMo/Resources|Resource Rep]]. }}


When screening the budget request (and the related event page), the mentor should use the assessment criteria set out in this SOP, as well their own knowledge of the Rep. Very importantly, the mentor needs to ensure that the event has a minimum of 3 success scenarios and metrics, chosen from the following list of success criteria: https://remo.etherpad.mozilla.org/success-criteria
{{admon/important|Budget Bug at your Event Page|Once you open a budget request, make sure that you have added the bug number on the event page. }}


This screening phase is to ensure the request is clear with solid success scenarios that can be measured. It is also an opportunity for the mentor to provide any additional details that may help the ReMo Council's final decision. '''NB: A mentor cannot decide whether or not a budget should be approved, the mentor is tasked to make sure the budget request is valid for review'''.
==Budget guidelines table==
There are certain services that you can ask to be reimbursed at a budget request. Here are the categories and the list of services that a rep can ask:
{| class="wikitable" style="text-align: center; height:100%; width:100%;"
|-
! Reimbursement list -<br> Event Category !! !!colspan="2" | Community meet-up / Intercommunity meet-up !! rowspan="2" | Industry and FOSS events !! colspan="3" | Specific Hackathons<br> (WebVR, Rust, Firefox, etc) !! colspan="3" | General events<br> (talks in university,<br> booths in local events) !! rowspan="2" | MozCoffee !! rowspan="2" | Moz Tours
|-
| || subcategories || up to 10 participants || 10-100 participants || up to 50 participants || 50-200 participants || more than 200 participants || up to 50 participants || 50-200 participants || more than 200 participants
|-
| rowspan="2" |Travel || for the organizers || style="color: red;" | no || style="color: green;" | yes  || style="color: green;" | yes || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: green;" | yes
|-
| for the participants|| style="color: red;" | no || style="color: green;" | yes || style="color: green;" | yes || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no
|-
| rowspan="2" |Local transportation|| for the organizers || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: red;" | no || style="color: green;" | yes || style="color: green;" | yes || style="color: red;" | no || style="color: green;" | yes || style="color: green;" | yes || style="color: red;" | no || style="color: red;" | no
|-
|for the participants || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no
|-
| rowspan="2" |Accommodation || for the organizers || style="color: red;" | no || style="color: green;" | yes || style="color: green;" | yes || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: green" | yes
|-
|for the participants || style="color: red;" | no || style="color: green;" | yes || style="color: green;" | yes || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no
|-
| rowspan="2" |Food and Drinks (no alcoholic beverages) || for the organizers || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: red;" | no || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: red;" | no
|-
| for the participants || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: green;" | yes || style="color: red;" | no
|-
| Supplies/<br>Miscellenious || || style="color: red;" | no || style="color: green;" | yes || style="color: red;" | no || style="color: green;" | yes || style="color: green;" | yes  || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: red;" | no || style="color: red;" | no
|-
| rowspan="2" |Swag || low budget gear (for example stickers, buttons etc) || style="color: green;" | yes || style="color: green;" | yes || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: green;" | yes
|-
|expensive gear (for example t-shirts) ||  style="color: red;" | no || style="color: green;" | yes (only for core contributors) ||  style="color: red;" | no ||  style="color: red;" | no ||  style="color: red;" | no ||  style="color: red;" | no ||  style="color: red;" | no ||  style="color: red;" | no ||  style="color: red;" | no ||  style="color: red;" | no ||  style="color: red;" | no
|-
| Visa fees ||  || style="color: red;" | no || style="color: green;" | yes || style="color: green;" | yes || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no
|-
| Courrier fees ||  || style="color: red;" | no || style="color: green;" | yes || style="color: green;" | yes || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no
|-
| Venue || || style="color: red;" | no || style="color: green;" | yes || style="color: red;" | no || style="color: red;" | no || style="color: green;" | yes || style="color: green;" | yes || style="color: red;" | no || style="color: green;" | yes || style="color: green;" | yes || style="color: red;" | no || style="color: red;" | no
|-
| WiFi at the venue ||  || style="color: red;" | no || style="color: green;" | yes || style="color: red;" | no || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: red;" | no || style="color: red;" | no
|-
| Printing flyers ||  || style="color: red;" | no || style="color: red;" | no || style="color: red;" | no || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: green;" | yes || style="color: red;" | no || style="color: red;" | no
|-


*If mentor considers the budget request to be valid for review:
|}
{{admon/note|Not being approved by default|It's important to understand, that these are not 'all the things Mozilla will cover, but rather, things that might be considered with supporting metrics, and where diligence has been given to alternative solutions (like community partnerships, and donation)}}


    Bug Status : NEW
= Disbursement of Funds =
    Bug Whiteboard : Valid for review
    Set remo-review flag to +


*If the mentor does NOT consider the budget request to be valid for review:
In the primary comment of the bug, the Rep needs to define if he/she needs an advance payment or he/she wants to be reimbursed after the event is over.
There are 2 ways to be paid
1) paypal
2) wire transfer


    Bug Status : NEW
== Payment via Paypal ==
    Bug Whiteboard : NOT valid for review
In most of the cases we are using payment via Paypal because it is more easy and safer to proceed. The Rep should provide the bug wrangler his/her Paypal account in order to proceed with the payment.
    Set remo-review flag to -
The transaction costs on Paypal are not to be paid by the Rep. Bug wrangler has to add an additional 4% of the amount in order to cover them.


*Disagreement of screening results
== Payment via wire transfer ==
In some cases, particularly in cases where Paypal does not exist in a specific country, payments can be made via wire transfer.
In order to proceed with this type of payment, the ReMo payment coordinator must follow these specific steps:


Should the applying Rep, or any other following the request disagree with the mentor, they should voice their concerns to the council via the council alias reps-council@mozilla.com
*collect an invoice (or pro-forma invoice in case of advanced payment) from the Rep
*fill out the dedicated wire transfer form
*send an email to Mozilla accounting and attach the invoice and the corresponding wire transfer form
*update the budget request bug to inform that payment has been processed via wire transfer


=== Filtering phase ===
Once the bug is being paid the bug wrangler leaves the following comment:


A member of the Budget Task Force will filter out those requests that are not considered relevant or appropriate. All remaining requests are then passed on to a ReMo Council member for final review and approval/rejection.
  Payment has been processed, please confirm
Whiteboard is being changed to:
  [approved][full processed][waiting for receipts][waiting for report and photos]


*If budget task force considers the budget request to be valid for review:
As soon as the rep is notified by the the bug wrangler that he/she has been reimbursed, '''he/she should confirm the reimbursement by attaching a screenshot of the transaction indicating how much the rep received on local currency.'''


    Bug Status : ASSIGNED
'''Want to know more about our accounting rules? check this [[ReMo/SOPs/Budget/Accouting-Rules|page]]'''
    Bug Whiteboard : Council Reviewer Assigned
    Set remo-approval flag to ?


*If the budget task force does NOT consider the budget request to be valid for review:
== Follow-up ==
The bug wrangler must carry-out a follow-up of of all projects whose budget requests have been approved and update the bugs regularly.


    Bug Status : RESOLVED - WONTFIX
Things that the Rep must submit after the event is done:
    Bug Whiteboard : NOT valid for council review
*receipt (see the guideline [[ReMo/SOPs/Budget/Receipts_guide|here]])
    Set remo-approval flag to -
*budget breakdown
*blogpost and photos
*post event metrics


=== ReMo Council approval or rejection ===
== Payment after the event is completed ==
In case you want to be reimbursed after your event make sure you would have all the mentioned things on the follow-up section completed and notify the bug wrangler that you’ve submitted all your receipts.


•  Requests < $500 USD: assigned reviewer is any member of the Budget Task Force and can approve/reject request without consulting the council <br>
Once the bug is being paid the bug wrangler leaves the following comment:
  Payment has been processed, please confirm


    Bug Status : ASSIGNED
{{admon/note|submission of receipts The rep has to submit his/her receipts on a 2 weeks period after the event. If the rep fails to submit his/her receipts then the rep is going to be reimbursed based on the exchange rate the date that the receipts were printed. The bug wrangler will use [http://www.oanda.com oanda] historical rates.}}
    Bug Whiteboard : Budget Approved or Budget Rejected
    Set remo-approval flag to + or -


•  Requests > $500 USD: assigned reviewer must be a council member and  must approve/reject request with prior deliberation of ReMo Council over email or IRC. Approval of budget can only be made if council approves  with a majority.<br>
== Tolerance threshold for events going "over" budget ==
*Budgets < $500 USD: maximum of 30% over-budget
*Budgets > $500 USD: maximum of 20% over-budget
*Budgets > $5,000 USD: maximum of 10% over budget


    Bug Status : ASSIGNED
{{admon/important|Overbudget: A rep can go overbudget only in cases of unexpected costs. Each overbudget case will be reviewed by the Rep’s mentor.}}
    Bug Whiteboard : Budget Approved or Budget Rejected
    Set remo-approval flag to + or -


•  Requests > $5,000 USD: assigned reviewer must be a council member  and must approve/reject request with prior deliberation of ReMo Council  over email or IRC. Approval of budget can only be made if council  approves unanimously.<br>
=Tracking and Follow-up=
The bug wrangler must carry-out a follow-up of all projects whose budget requests have been approved and update the bugs regularly.


    Bug Status : ASSIGNED
= Contact =
    Bug Whiteboard : Budget Approved or Budget Rejected
For any questions, suggestions or comments, please also contact [https://mozillians.org/en-US/u/couci/ Konstantina], [https://mozillians.org/en-US/u/kelimutu/ Kiki], or [https://mozillians.org/en-US/u/nukeador/ Ruben].
    Set remo-approval flag to + or -


== Special Cases ==
[[Category:Remosop]]
 
In some cases, Reps will be owning an event that is already sponsored by Mozilla and therefore, DO NOT require Council budget approval. For these special cases, the Reps needs to '''[[ReMo/SOPs/Budget/Special_Cases|follow this procedure]]'''.
 
== Accounting Rules ==
 
The fund flow should comply with accounting rules.<br>
 
A donation is usually an amount given to an established non-profit organization with an established charter and its own auditing processes. It is usually not linked to a specific project but just to partially support the overall goal of this organization.<br>
 
Expenses covered must be related to a ReMo event/project (with a proper ReMo event wiki page) as they occur, or once they have occurred.<br>
 
In general, event-related expenses are covered once the event has occurred, besides advanced payment such as a portion of a proposal for a room, technical equipment rental, catering at the event. The remaining due amount is then paid just before the event, or upon receipt of a bill. In all cases such documents/offers should be formalized once the project has been approved with amounts/due dates and bank info so payments can be made accordingly.<br>
 
In general, individual expenses are covered by paying back expense notes submitted with receipts, to cover individual travel, accommodation and food falling within pre-approved limits/guidelines. In some cases some of these expenses (travel, accommodation) could be directly paid to the service provider beforehand by Mozilla, which then provides the airline ticket or the hotel room to the individual. Food, taxi and other limited expenses are still reimbursed through an expense note.<br>
 
== Disbursement of Funds ==
 
Once a budget request has been approved, William Quiviger must process payments via PayPal or Western Union provided all relevant receipts and/or pro-forma invoices are attached to the budget request bug. It is currently not possible to make payment via bank transfer.
 
=== Tolerance threshold for events going "over" budget ===
 
* Budgets < $500 USD: maximum of 30% over-budget <br>
 
* Budgets > $500 USD: maximum of 20% over-buget <br>
 
* Budgets > $5,000 USD: maximum of 10% over budget <br>
 
== Tracking and Follow-up ==
 
The ReMo Council must regularly track the status of all pending budget requests and carry-out a follow-up of all projects whose budget requests have been approved. All this information must be available to the public on the Mozilla wiki and on Bugzilla.<br>
 
a) Budget Request Tracking<br>
 
All budget requests should be tracked based on 5 different bugzilla whiteboard statuses :
<br>
*<b>Reviewer Assigned</b> : budget request fits all the selection criteria, and a person from the ReMo council has been assigned as reviewer<br>
*<br>Reviewer Assigned - need unanimous sign-off from Council</b>
*<b>Budget Approved</b> : budget request has been approved and signed off by reviewer (and a majority of members of ReMo Council if > $500 USD and unanimously if > $5,000 USD), and the funded project is now in the process of disbursement<br>
** Approval comment on bug must say:<br>
<pre>
 
Hi [first name], thanks for submitting this request. Your request has been approved. Please follow these next steps
before we can process your payment:
- indicate the twitter hashtags, flickr photos and blog posts related to your event on this bug and on your event wiki page
- provide a paypal account
- scan and attach all relevant receipts to this bug
 
Thanks and good luck for your event!
 
William
 
</pre>
*<b>Payment Processing</b> : payment process is underway<br>
*<b>Payment Processed</b> : all elements in the budget have been documented for payment and all payments have been made.<br>
*<b>Payment Received</b> : submitter has confirmed that (s)he has received the requested funds<br>
*<b>Rejected</b> : budget request was rejected by ReMo Council and/or during initial filtering phase<br>
 
The following information must be properly documented :<br>
• Name of Mozilla Rep<br>
• Community (if applicable)<br>
• Country<br>
• Project/Name name and wiki page<br>
• Date Budget Request was submitted<br>
• Date Budget Request was Approved<br>
• Date funds were Disbursed<br>
• Amount Requested<br>
 
[[Image:Budget_request_follow_up.png]]
 
== Contact ==
 
For any questions, suggestions or comments, please also contact William Q or Pierros.

Latest revision as of 19:44, 29 September 2023

Warning signWarning: With effect from 1st September 2023, the Mozilla Reps program was closed and activities ended.

MozRep-Final-Outline.png Main | Join | Procedures (SOPs) | Leadership (Resources) | Meetings | Website | FAQ


Overview

In order to effectively support Mozilla Rep activities/projects around the world, a budget request SOP exists to evaluate, approve budget requests submitted by Mozilla Reps and efficiently disburse funds.

This SOP outlines/answers the following questions:

What questions should I ask myself before requesting a budget

  • Opening a bug can be a lot of work. Make sure that you have answered all the questions mentioned on the assessment criteria before you open your bug. If you’re not sure about a question please don’t hesitate to reach out to your mentor. He/She will be able to help you plan your event.

What things do I have to check to submit a budget

  • So what is the information that I need to add in my bug and my event page so my bug can be ready for review? On the budget guidelines section you will be able to find a small checklist with the necessary things, a small blogpost from Regnard and a table with all the things that can be approved in the Program

How does the process work once I submitted the budget?

  • The Reps program follows a double approval procedure. Check the procedure page for more technical details.

What should I do to get reimbursed before and after the event?

  • So you got approval but you’re unsure on how you will receive the funds. Check the Disbursement of Funds and Follow up.

Can we use left over budget from the other event?

  • The Reps should file a new budget request in order to use the budget even if s/he already have the budget. Reps are not allowed to use the budget without advance approval from the review team.

Assessment Criteria

The Assessment Criteria for Budget Requests can be found on ReMo/SOPs/Budget/Assessment-Criteria.

Disqualification of Budget Requests

Budget requests received less than 3 weeks before the targeted launch date of the event/activity in question will automatically be rejected (exceptions can be made but only with council approval).

This 3-week “buffer” guarantees that each budget request undergoes the same thorough selection process.

Budgets that don't reply to the basic information asked in this SOP will be moved back to mentor review.

Basic information to be provided:

  1. Which functional area goals is this supporting and how?
  2. What are the event goals? What's success for this event? How are you going to measure it?
  3. Why this budget is needed for the success of the event?
  4. Detailed agenda (what are we doing, activities to support the event goals)
  5. Budget breakdown attached to the bug once created (who are we covering?)
  6. Are there "optional" costs not needed for the success of the event? Which ones? What the minimum viable budget?
Important.png
Receipts from previous budget requests
Make sure that you have attached all of your receipts at your previous budget requests. Reps that haven't submitted previous receipts will not be able to request budget for their new events.

Budget Guidelines

Budget Checklist

Here is a short checklist with all the things you need to have into your budget request before submitting it:

  • number of attendees expected at the event
  • venue
  • date
  • description and purpose of the event
  • event schedule / agenda
  • list of other mozillians who are going to participate
  • target audience
  • 3 success metrics
  • clear break down of expenses (form made by Michael Kohler based on the template the Filipino community is using)

As an additional resource, it would be recommended for Reps to read The Quick Guide to Writing Budget Requests for Mozilla Reps.

Note.png
Filing a Budget Request
To request a budget, get in touch with a Resource Rep.
Important.png
Budget Bug at your Event Page
Once you open a budget request, make sure that you have added the bug number on the event page.

Budget guidelines table

There are certain services that you can ask to be reimbursed at a budget request. Here are the categories and the list of services that a rep can ask:

Reimbursement list -
Event Category
Community meet-up / Intercommunity meet-up Industry and FOSS events Specific Hackathons
(WebVR, Rust, Firefox, etc)
General events
(talks in university,
booths in local events)
MozCoffee Moz Tours
subcategories up to 10 participants 10-100 participants up to 50 participants 50-200 participants more than 200 participants up to 50 participants 50-200 participants more than 200 participants
Travel for the organizers no yes yes no no no no no no no yes
for the participants no yes yes no no no no no no no no
Local transportation for the organizers yes yes yes no yes yes no yes yes no no
for the participants yes yes yes no no no no no no no no
Accommodation for the organizers no yes yes no no no no no no no yes
for the participants no yes yes no no no no no no no no
Food and Drinks (no alcoholic beverages) for the organizers yes yes yes yes yes yes no yes yes yes no
for the participants yes yes yes yes yes no no no no yes no
Supplies/
Miscellenious
no yes no yes yes yes yes yes yes no no
Swag low budget gear (for example stickers, buttons etc) yes yes no no no no no no no no yes
expensive gear (for example t-shirts) no yes (only for core contributors) no no no no no no no no no
Visa fees no yes yes no no no no no no no no
Courrier fees no yes yes no no no no no no no no
Venue no yes no no yes yes no yes yes no no
WiFi at the venue no yes no yes yes yes yes yes yes no no
Printing flyers no no no yes yes yes yes yes yes no no
Note.png
Not being approved by default
It's important to understand, that these are not 'all the things Mozilla will cover, but rather, things that might be considered with supporting metrics, and where diligence has been given to alternative solutions (like community partnerships, and donation)

Disbursement of Funds

In the primary comment of the bug, the Rep needs to define if he/she needs an advance payment or he/she wants to be reimbursed after the event is over. There are 2 ways to be paid 1) paypal 2) wire transfer

Payment via Paypal

In most of the cases we are using payment via Paypal because it is more easy and safer to proceed. The Rep should provide the bug wrangler his/her Paypal account in order to proceed with the payment. The transaction costs on Paypal are not to be paid by the Rep. Bug wrangler has to add an additional 4% of the amount in order to cover them.

Payment via wire transfer

In some cases, particularly in cases where Paypal does not exist in a specific country, payments can be made via wire transfer. In order to proceed with this type of payment, the ReMo payment coordinator must follow these specific steps:

  • collect an invoice (or pro-forma invoice in case of advanced payment) from the Rep
  • fill out the dedicated wire transfer form
  • send an email to Mozilla accounting and attach the invoice and the corresponding wire transfer form
  • update the budget request bug to inform that payment has been processed via wire transfer

Once the bug is being paid the bug wrangler leaves the following comment:

  Payment has been processed, please confirm 

Whiteboard is being changed to:

  [approved][full processed][waiting for receipts][waiting for report and photos]

As soon as the rep is notified by the the bug wrangler that he/she has been reimbursed, he/she should confirm the reimbursement by attaching a screenshot of the transaction indicating how much the rep received on local currency.

Want to know more about our accounting rules? check this page

Follow-up

The bug wrangler must carry-out a follow-up of of all projects whose budget requests have been approved and update the bugs regularly.

Things that the Rep must submit after the event is done:

  • receipt (see the guideline here)
  • budget breakdown
  • blogpost and photos
  • post event metrics

Payment after the event is completed

In case you want to be reimbursed after your event make sure you would have all the mentioned things on the follow-up section completed and notify the bug wrangler that you’ve submitted all your receipts.

Once the bug is being paid the bug wrangler leaves the following comment:

 Payment has been processed, please confirm
Note.png
submission of receipts The rep has to submit his/her receipts on a 2 weeks period after the event. If the rep fails to submit his/her receipts then the rep is going to be reimbursed based on the exchange rate the date that the receipts were printed. The bug wrangler will use oanda historical rates.

Tolerance threshold for events going "over" budget

  • Budgets < $500 USD: maximum of 30% over-budget
  • Budgets > $500 USD: maximum of 20% over-budget
  • Budgets > $5,000 USD: maximum of 10% over budget
Important.png
Overbudget: A rep can go overbudget only in cases of unexpected costs. Each overbudget case will be reviewed by the Rep’s mentor.

Tracking and Follow-up

The bug wrangler must carry-out a follow-up of all projects whose budget requests have been approved and update the bugs regularly.

Contact

For any questions, suggestions or comments, please also contact Konstantina, Kiki, or Ruben.