On Wed, Feb 15, 2017, at 10:51 PM, Robert Mayr wrote:
Please take this as potential horrible reply too :)

2017-02-15 18:14 GMT+01:00 Brian Exelbierd <bex@pobox.com>:



Warning potentially horrible idea follows:


Would it make sense to try split the Swag trac in Pagure so that we can stay as open as possible yet still shield people's private data (which I believe is the biggest concern)?  An idea, possibly a horrible one is:

Yes the private data is the biggest concern here.
 


1. Ambassador SWAG and other requests are handled inan open Pagure instance.  Once the request is approved, it is set to either closed or waiting (not sure I have a preference).

If we want an opne pagure instance and split all the tickets, doubling the work for ambassadors,

I am not seeing how this doubles the work for ambassadors, perhaps you can help me.  I think the workflow is:

1. Have something that you want funded by Fedora
2. Open a pagure ticket in the regional track and request funding approval
3. Funding is approved and noted in the ticket
4. Do the thing
5. Open a ticket in the budget track and include a link to the funding approval ticket from #2
6. Upload your receipts
7. Get reimbursed

Step 5 is the only extra step.  I don't see that step as doubling the effort.  It is, as far as I can tell, literally the extra work of:
1. Copy url
2. Click new issue
3. Paste url

Everything else is the same.

What have I missed?

then we need to close and archive the old trac. You cannot just migrate the swag trac as a normal pagure repo. I don't know anything about other regional tracs, but the EMEA trac has even tickets per single FAS account in the past. Making them public is a no-go.  The only way I see is migrating them as private tickets and set new tickets as default to public.

I am don't have an opinion on what should happen to the old data.  There are lots of good comments by others so I defer to them.  I am only thinking about a way that we can have an effective workflow from today (in Pagure) forward and require the fewest customizations and feature changes to Pagure so that we eliminate blockers.

2. When the purchase is completed a new ticket is opened privately in fedora-budget.  This is the ticket where receipts and payment information are placed.  This is closed to just the budget folks (FCAIC, treasurers, card holders).  The reimbursement/payment is processed.  This ticket includes the reference to the public ticket opened in #1.
3. The public ticket, if not already closed is closed with an update stating the total paid.

While the idea is not bad, I see some issues with filing all these tickets. An additional  help could be to make a template in the budget repo, where people are just asked to fill out some data: ticket number of the swag repo, amount, payment information etc.

+1 I definitely support templating here.  I also believe that funding request tickets should be templated too.

 


It creates an extra step for the payment processors (#3), but I don't think it represents a lot of work (there is a link in #2).  This also allows us to more easily track receipts in a closed way while being very open about the approval process.  That is a HUGE win for audit purposes.

The main goal should be to migrate the tickets correctly and keep private data private, not auditing or statistics.

I look at the migration separately from protecting information in a new workflow.  I am only addressing the information protection in the new workflow.

Also, while audit is not a primary goal, a successfully auditable system ensure that our financial needs will not get blocked on process problems.  If we can get that as a bonus, it serves to help us.

regards,

bex

 


An added bonus is that at times when meeting cards run out of credit limit or we reach the end of the FY, all payers are in the same place and can jump in to help each other out more easily.

WDYT?

regards,

bex




--
Robert Mayr
(robyduck)
_______________________________________________
ambassadors mailing list -- ambassadors@lists.fedoraproject.org
To unsubscribe send an email to ambassadors-leave@lists.fedoraproject.org



_______________________________________________
ambassadors mailing list -- ambassadors@lists.fedoraproject.org
To unsubscribe send an email to ambassadors-leave@lists.fedoraproject.org




--
Robert Mayr
(robyduck)
_______________________________________________
ambassadors mailing list -- ambassadors@lists.fedoraproject.org
To unsubscribe send an email to ambassadors-leave@lists.fedoraproject.org