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(a)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(a)lists.fedoraproject.org
>>> To unsubscribe send an email to ambassadors-
>>> leave(a)lists.fedoraproject.org
>
>
>
> _______________________________________________
> ambassadors mailing list -- ambassadors(a)lists.fedoraproject.org
>> To unsubscribe send an email to ambassadors-
>> leave(a)lists.fedoraproject.org
>
--
Robert Mayr
(robyduck)
_________________________________________________
ambassadors mailing list -- ambassadors(a)lists.fedoraproject.org
To unsubscribe send an email to ambassadors-
leave(a)lists.fedoraproject.org