Reps/SOPs/Budget: Difference between revisions

Warning added
(Warning added)
 
(47 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{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.}}
{{Remonav}}
__TOC__
= Overview =
= Overview =


Line 5: Line 11:
This SOP outlines/answers the following questions:
This SOP outlines/answers the following questions:


*What questions should I ask myself before requesting a budget?
==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.
*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.
==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
*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.
==How does the process work once I submitted the budget?==
*What should I do to get reimbursed before and after the event?
*The Reps program follows a double approval procedure. Check the [[ReMo/SOPs/Budget/Process|procedure page]] for more technical details.
**So you got approval but you’re unsure on how you will receive the funds. Check the Disbursement of Funds and  Follow up.
 
==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 =
= Assessment Criteria =


== Main focus areas ==
The Assessment Criteria for Budget Requests can be found on [[ReMo/SOPs/Budget/Assessment-Criteria]].
 
*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:
*Which goals is this event supporting?
*How this budget is important for the success of the event?
*Does this opportunity represent a relatively small level of financial support that will have a large impact on others in the Mozilla community?
*Does the project empower other members of the community?
*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?
*How measurable is the success of the event/activity and how easy is the follow-up ?
*'''Does this budget directly impact a functional area goal?'''


== Disqualification of Budget Requests ==
== Disqualification of Budget Requests ==
Line 32: Line 34:


This 3-week “buffer” guarantees that each budget request undergoes the same thorough selection process.
This 3-week “buffer” guarantees that each budget request undergoes the same thorough selection process.
<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.'''
Basic information to be provided:
<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>
</div>


{{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.}}
{{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.}}
Line 46: Line 64:
*target audience
*target audience
*3 success metrics
*3 success metrics
*clear break down of expenses  
*[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)


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]'''.
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]'''.


{{admon/note|Filing a Budget Request|To request a budget, the following '''[https://bugzilla.mozilla.org/form.reps.budget budget request form]''' needs to be completed and submitted. }}
{{admon/note|Filing a Budget Request|To request a budget, get in touch with a [[ReMo/Resources|Resource Rep]]. }}


{{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. }}
{{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. }}


= Processing =
==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
|-


The process of budget requests is made up of three distinct phases:
|}
{{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)}}


1) preliminary screening made by the Rep's mentor<br>
= Disbursement of Funds =
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>


== Preliminary Screening ==
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.
=== Requesting Review using flags ===
There are 2 ways to be paid
* Bug wrangler (Konstantina) assigns the bug to mentor
1) paypal
2) wire transfer


  Bug Status : NEW
== Payment via Paypal ==
  Bug Whiteboard : Reviewer Assigned
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.


=== Screening by the mentor ===
== 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.
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
In order to proceed with this type of payment, the ReMo payment coordinator must follow these specific steps:
 
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.
{{admon/important|Mentors DO NOT approve budgets| A mentor cannot decide whether or not a budget should be approved, rather, the mentor is tasked to make sure the budget request is <u>valid</u> for review}}
 
*If mentor considers the budget request to be valid for review:
 
    Bug Status : NEW
    Bug Whiteboard : Valid for review
    Set remo-review flag to +
 
*If the mentor does NOT consider the budget request to be valid for review:
 
    Bug Status : NEW
    Bug Whiteboard : NOT valid for review
    Set remo-review flag to -
 
*Disagreement of screening results
 
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
{{admon/important|Mentors commenting on the bugs| A mentor should leave a comment on the bug to briefly explain why he/she thinks that the request is valid or not valid for review, and even more importantly how it can be made better.}}
 
== Filtering phase ==
Bug wrangler (Konstantina) 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.
 
*If remo-review is + then the bug wrangler assigns the bug conditionally :
** If budget request is <500 USD then it is assigned to a regional council member
 
    Bug Status : ASSIGNED
    Bug Whiteboard : Council Reviewer Assigned
    Set remo-approval flag to ?
 
**If budget request is >500 USD then it is assigned to reps-council
 
    Bug Status : ASSIGNED
    Bug Whiteboard : Council approval needed
    Set remo-approval flag to ?
 
*If remo-review is - then the bug wrangler resolves the bug rejecting it
 
    Bug Status : RESOLVED - WONTFIX
    Bug Whiteboard : NOT valid for council review
    Set remo-approval flag to -
 
=== Council Member Assignment for budgets OVER $500 USD ===
 
For budgets over $500 USD, there should still be a single council reviewer assigned.
 
The flag called "needs-info" should be set against it the Mozilla Reps Council alias on bugs that need council's attention. The process must be as follows:
 
* A SINGLE council member is assigned to the bug
* That person can ask the Rep for any obvious missing info, but needs-info? is set to reps-council@mozilla.com, causing the alias to get an email
* An e-mail is sent automatically to the council starting the discussion period which lasts for 48hrs
* After the discussion period is over, the council members have 72 hours to cast their vote on the portal.
* When voting is closed, "needs-info" is canceled and "reps-approval" is set to + or -
 
== ReMo Council approval or rejection ==
 
•  Requests < $500 USD: assigned reviewer is a member of the reps council and can approve/reject request without consulting the council
 
    Bug Status : ASSIGNED
    Set remo-approval flag to + or -
 
•  Requests > $500 USD: assigned reviewer must be a council member who is responsible for udating the request. Approval of budget can only be made if council approves  with a majority.
 
    Bug Status : ASSIGNED
    Set remo-approval flag to + or -
    Set need-info flag to ? for reps-council@mozilla.com
•  Requests > $5,000 USD: assigned reviewer must be be a council member who is responsible for udating the request. Approval of budget can only be made if council  approves unanimously.
 
    Bug Status : ASSIGNED
    Set remo-approval flag to + or -
    Set need-info flag to ? for reps-council@mozilla.com
 
Approval comment on bug must say:
 
<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!
Reviewers name (either a council member or a council member on behalf of the council)
</pre>
 
Once the bug is approved the bug wrangler (Konstantina) assigns of the bug back to the requester Rep.
 
{{admon/important|Council Encouragement| A denied budget is not the end of the road, and council should update budgets with suggestions as to what part of the budget (if any) they do support for revision, and resubmission in future.}}
 
== Tracking and Follow-up ==
 
We are using a module system for keywords to use on the whiteboard. The bug wrangler or reviewer must use the appropriate combination of modules to clearly point to expected actions relevant to the bug.
 
Prefixes (only one):
*;[approved]: budget has been approved
 
*;[rejected]: budget has been rejected
 
*;[closed]: whiteboard status for resolved fixed budget. In this case STATUS changes to RESOLVED FIXED
 
Suffixes (multiple):
*;[advance needed full]: the full amount of funds needs to be processed in advance
 
*;[advance needed partial]: a partial amount of funds needs to be processed in advance
 
*;[approved partial]: council or the council member reviewer have approved only a partial amount of the expenses
 
*;[waiting receipts]: receipts are needed in order the bug wrangler to make the payment
 
*;[waiting report and photos]: report and photos are needed in order the bug wrangler can close the bug
 
*;[receipts received]: receipts have been received from the bug wrangler
 
*;[WU needed]: funds need to be processed via Western Union
 
*;[XXX USD processed]: XXX amount of money has been processed
 
*;[special]: In some cases, Reps will be owning an event that is already sponsored by Mozilla and as such, DO NOT require Council budget approval. For these special cases, the Reps needs to '''[[ReMo/SOPs/Budget/Special_Cases|follow this procedure]]'''.
 
*;[special deveng]: In some cases, Reps will be owning an event that is already sponsored by Mozilla's Developer Engagement Team and as such, DO NOT require Council budget approval. These events are overseen by Robyn Chau.
 
*;[full processed]: bug wrangler has made a full payment
 
*;[FR=AMOUNT]: indicated final amount request (For example, if the final amount requested is $800 USD, then the whiteboard should indicate [FR800]
 
= 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.
 
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.


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.
*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


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.
Once the bug is being paid the bug wrangler leaves the following comment:


= Disbursement of Funds =
  Payment has been processed, please confirm
Whiteboard is being changed to:
  [approved][full processed][waiting for receipts][waiting for report and photos]


Once a budget request has been approved, Konstantina Papadea must process payments via PayPal or wire transfers provided all relevant receipts and/or pro-forma invoices are attached to the budget request bug. The rep has the choice to ask for an advance payment, or to be reimbursed once he/she has submitted all the relevant receipts, event reports 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.'''


==Advance Payment==
'''Want to know more about our accounting rules? check this [[ReMo/SOPs/Budget/Accouting-Rules|page]]'''


In the case that the rep has asked for an advance payment, he/she should determine whenever he/she prefers to be paid via paypal or via wire transfer (please see details below). 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.
== Follow-up ==
After the event is completed, the rep should provide a detailed spreadsheet indicating how much he/she spent in local currency. Based on that, the bug wrangler will review the receipts based on the local currencies and will calculate if the rep is left with an extra amount or need to be reimbursed. In the case that a rep went "over-budget" he/she will be reimbursed once he/she has submitted all his reports and photos and by his/her mentor's approval.
The bug wrangler must carry-out a follow-up of of all projects whose budget requests have been approved and update the bugs regularly.


==Payment after the event is completed==
Things that the Rep must submit after the event is done:
In the case that the reps doesn't requested an advance payment, then the bug wrangler will pay the rep based on the paypal's current rates.  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 excange rate the date that the receipts were printed. The bug wrangler will use oanda.com [http://www.oanda.com/currency/converter/] historical rates.
*receipt (see the guideline [[ReMo/SOPs/Budget/Receipts_guide|here]])
*budget breakdown
*blogpost and photos
*post event metrics


==Payment via paypal==
== 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.


In the most of the cases we are using payment via paypal because it is more easy and safe to proceed. The rep should provide the bug wrangler his/her paypal account in order to proceed with the payment.
Once the bug is being paid the bug wrangler leaves the following comment:
  Payment has been processed, please confirm


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.
{{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.}}
 
== Payment via wire transfer ==
 
In some cases, particularly in cases where paypal does not exist in a specific country and/or the amount to be paid for an individual expense is over $500 USD, 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:
 
1) collect an invoice (or pro-forma invoice in case of advanced payment) from the Rep <br>
2) fill out the dedicated '''[https://wiki.mozilla.org/images/d/de/Wire_transfer_Template.xls wire transfer form]''' <br>
3) send an email to Mozilla accounting and attach the invoice and the corresponding wire transfer form <br>
4) update the budget request bug to inform that payment has been processed via wire transfer <br>


== Tolerance threshold for events going "over" budget ==
== 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


* Budgets < $500 USD: maximum of 30% over-budget
{{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.}}
 
* Budgets > $500 USD: maximum of 20% over-buget
 
* Budgets > $5,000 USD: maximum of 10% over budget


=Tracking and Follow-up=
=Tracking and 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 regurarly.
The bug wrangler must carry-out a follow-up of all projects whose budget requests have been approved and update the bugs regularly.


= Contact =
= Contact =
For any questions, suggestions or comments, please also contact Konstantina, Rosana, or Ruben.
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].


[[Category:Remosop]]
[[Category:Remosop]]
332

edits