On Thu, Feb 16, 2017, at 04:17 PM, Robert Mayr wrote:
2017-02-16 14:51 GMT+01:00 Brian Exelbierd <bex(a)pobox.com>:
> __On Wed, Feb 15, 2017, at 10:51 PM, Robert Mayr wrote:
>> [snip]
>
>
>> 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?
The extra stuff might cause problems. I know people sometimes are
having difficulties even to file a correct ticket on the swag trac,
you can immagine if we add a thing like "then open a new ticket where
you have to write this this and that".
We should simplify things as much as possible instead of
complicating them.
Honestly, if someone is going to fail in this process, I think they are
going to fail even without having to open a second ticket. I believe
this process is very simple and with the templating functions of Pagure
can be made easy. However, if everyone thinks this is complicated then
we don't have to do it. Based on your comment though, what we are doing
today isn't working either.
>
>
>>> 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.
You cannot separate this and just look at what you are interested
in.
Unless you want to archive the old data and make it accessible only
for trac admins through a DB dump.
Yes I can. I am concerned with having a great workflow for tomorrow,
not with litigating the past. I do not feel like we need to tie
ourselves to what we did yesterday especially when we are at an
inflection point like this (moving to new tools and changing fiscal
years). I am not familiar with why immediate access to this old data is
critical so I am not going to offer an opinion on whether importing it
in a restricted way is better than auditing it or just having a dump
available if needed. I hope others who have found the need for the
historical data useful can weigh in on that.
I am focused on having the best possible workflow for tomorrow.
>
>>> 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.
Cool :D
>
>
>
>>
>>
>
>>
>
>>>> 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.
Same as above. If you just care about what is important for your
process now, you don't get all points we need to fill. In that case we
will need to find a solution anyway (just archiving is one of it, but
not really a good one).
Our answer for what we do with old data doesn't have to be a gating
factor for how we move forward in the future. These do not have to be
tied together. How we handle data from the old tool should not dictate
how we are allowed to work in the future. We have to be able to adapt
to new tools, ideas, and options.
Did you at least think about actual open tickets?
It seems to me that we probably only have a few kinds of open tickets.
I also hope we have as few open tickets as possible and can make a push
to close as many as possible prior to migration.
1. Tickets unrelated to expenses/swag/travel/etc. Migrate these as
publictickets or private tickets as appropriate.
2. Tickets that are in progress requesting approval to spend money.
Migrate these as open tickets and follow the new workflow.
3. Approved expense requests that are waiting for the expenditure or
travel to happen still. Migrate these as publictickets and then
follow the new workflow.
3. Tickets that are waiting on reimbursements. Ideally just pay them
out and close them before migration. If this is not possible for
some reason, either migrate them as private tickets and handle
these as exceptions or manually bifurcate the ticket and follow the
new workflow.
I hope we are talking about only a few tickets. If we have a ton of
open tickets I think we need to stop and ask ourselves if our processes
are working.
regards,
bex
>
> regards,
>
> bex
>
>
>
Kind regards.
--
Robert Mayr
(robyduck)
_________________________________________________
ambassadors mailing list -- ambassadors(a)lists.fedoraproject.org
To unsubscribe send an email to ambassadors-
leave(a)lists.fedoraproject.org