REMINDER: EMEA Ambassadors Meeting 2017-02-15

[Nemanja Milosevic]

Hey EMEA Ambassadors,

We're going to have our regular meeting tomorrow. See below for more info:
* Date: Wednesday, February 15th, 2017
* Time: 20:00 UTC
* Location: #fedora-meeting @ freenode
* Meeting Agenda:
  - Roll Call
  - Announcements
  - Requests
  - Ambassadors Schedule
  - Events
  - Action items from previous meetings
  - Open Floor

If you have any requests that need to be discussed during the meeting,
make sure to file a ticket on trac.

Meet you there!
- Nemanja

[Robert Mayr]

Il 14/feb/2017 04:48 PM, "Nemanja Milosevic" <nmilosev(a)fedoraproject.org&gt;
ha scritto:

Hey EMEA Ambassadors,

We're going to have our regular meeting tomorrow. See below for more info:
* Date: Wednesday, February 15th, 2017
* Time: 20:00 UTC
* Location: #fedora-meeting @ freenode
* Meeting Agenda:
  - Roll Call
  - Announcements
  - Requests
  - Ambassadors Schedule
  - Events
  - Action items from previous meetings
  - Open Floor

If you have any requests that need to be discussed during the meeting,
make sure to file a ticket on trac.

Meet you there!
- Nemanja
_______________________________________________
ambassadors mailing list -- ambassadors(a)lists.fedoraproject.org
To unsubscribe send an email to ambassadors-leave(a)lists.fedoraproject.org


Is there anybody in charge to migrate the EMEA swag trac? Probably the
second question should  be *how* you plan to migrate it...
If not, could you add this to the Agenda? Deadline is in a couple of weeks.
Thanks.

--
Robert Mayr
(robyduck)

[Nemanja Milošević]

I'm unaware that anyone is in charge for the migration. I will definitely
bring it up tomorrow.

There is another thread on this list which mentions the migration,
hopefully someone there is more informed.

Cheers,
Nemanja

On Tue, Feb 14, 2017, 19:00 Robert Mayr <robyduck(a)fedoraproject.org&gt; wrote:

>  Il 14/feb/2017 04:48 PM, "Nemanja Milosevic"
> <nmilosev(a)fedoraproject.org&gt;
>  ha scritto:
>
>  Hey EMEA Ambassadors,
>
>  We're going to have our regular meeting tomorrow. See below for more info:
>  * Date: Wednesday, February 15th, 2017
>  * Time: 20:00 UTC
>  * Location: #fedora-meeting @ freenode
>  * Meeting Agenda:
>    - Roll Call
>    - Announcements
>    - Requests
>    - Ambassadors Schedule
>    - Events
>    - Action items from previous meetings
>    - Open Floor
>
>  If you have any requests that need to be discussed during the meeting,
>  make sure to file a ticket on trac.
>
>  Meet you there!
>  - Nemanja
>  _______________________________________________
>  ambassadors mailing list -- ambassadors(a)lists.fedoraproject.org
>  To unsubscribe send an email to ambassadors-leave(a)lists.fedoraproject.org
>
>
>  Is there anybody in charge to migrate the EMEA swag trac? Probably the
>  second question should  be *how* you plan to migrate it...
>  If not, could you add this to the Agenda? Deadline is in a couple of weeks.
>  Thanks.
>
>  --
>  Robert Mayr
>  (robyduck)
>  _______________________________________________
>  ambassadors mailing list -- ambassadors(a)lists.fedoraproject.org
>  To unsubscribe send an email to ambassadors-leave(a)lists.fedoraproject.org
>

[Sylvia]

Hello everyone,
I thought Justin was helping us with this. But maybe I mixed up with
FAmSCo that is migrating as well?

Cheers,Sylvia
On Tue, 2017-02-14 at 18:21 +0000, Nemanja Milošević wrote:
>  I'm unaware that anyone is in charge for the migration. I will
>  definitely bring it up tomorrow. 
>  
>  There is another thread on this list which mentions the migration,
>  hopefully someone there is more informed. 
>  
>  Cheers, 
>  
>  Nemanja 
>  
>  
>  On Tue, Feb 14, 2017, 19:00 Robert Mayr <robyduck(a)fedoraproject.org&gt;
>  wrote:
>  > Il 14/feb/2017 04:48 PM, "Nemanja Milosevic" <nmilosev@fedoraprojec
>  > t.org> ha scritto:
>  > Hey EMEA Ambassadors,
>  > 
>  > 
>  > 
>  > We're going to have our regular meeting tomorrow. See below for
>  > more info:
>  > 
>  > * Date: Wednesday, February 15th, 2017
>  > 
>  > * Time: 20:00 UTC
>  > 
>  > * Location: #fedora-meeting @ freenode
>  > 
>  > * Meeting Agenda:
>  > 
>  >   - Roll Call
>  > 
>  >   - Announcements
>  > 
>  >   - Requests
>  > 
>  >   - Ambassadors Schedule
>  > 
>  >   - Events
>  > 
>  >   - Action items from previous meetings
>  > 
>  >   - Open Floor
>  > 
>  > 
>  > 
>  > If you have any requests that need to be discussed during the
>  > meeting,
>  > 
>  > make sure to file a ticket on trac.
>  > 
>  > 
>  > 
>  > Meet you there!
>  > 
>  > - Nemanja
>  > 
>  > _______________________________________________
>  > 
>  > ambassadors mailing list -- ambassadors(a)lists.fedoraproject.org
>  > 
>  > To unsubscribe send an email to ambassadors-leave(a)lists.fedoraproje
>  > ct.org
>  > 
>  > Is there anybody in charge to migrate the EMEA swag trac? Probably
>  > the second question should  be *how* you plan to migrate it...
>  > If not, could you add this to the Agenda? Deadline is in a couple
>  > of weeks.
>  > Thanks.
>  > 
>  > --
>  > Robert Mayr
>  > (robyduck)
>  > _______________________________________________
>  > 
>  > ambassadors mailing list -- ambassadors(a)lists.fedoraproject.org
>  > 
>  > To unsubscribe send an email to ambassadors-leave(a)lists.fedoraproje
>  > ct.org
>  > 
>  > 
>  
>  _______________________________________________
>  ambassadors mailing list -- ambassadors(a)lists.fedoraproject.org
>  To unsubscribe send an email to ambassadors-leave(a)lists.fedoraproject
>  .org

[Robert Mayr]

2017-02-14 19:21 GMT+01:00 Nemanja Milošević <nmilosev(a)fedoraproject.org&gt;:

>  I'm unaware that anyone is in charge for the migration. I will
> definitely
>  bring it up tomorrow.
>
>  There is another thread on this list which mentions the migration,
>  hopefully someone there is more informed.
>
>  Cheers,
>  Nemanja
>
>  
The EMEA trac has many settings which aren't standard, so it is not a
normal migration like other tracs. Some of these settings are not doable on
pagure.
Not only it has FAS only access, but there should be also tickets
accessible per single FAS account. It should have even more particular ACLs
or defaults, so the question really is *how* we want to do it.
Mitzie should be trac admin, but I'm not sure, he can for sure help to know
all permissions and settings.


-- 
Robert Mayr
(robyduck)

[Brian Exelbierd]

On Tue, Feb 14, 2017, at 10:20 PM, Robert Mayr wrote:

>  2017-02-14 19:21 GMT+01:00 Nemanja Milošević
>  <nmilosev(a)fedoraproject.org&gt;:
> > I'm unaware that anyone is in charge for the migration. I will
> > definitely bring it up tomorrow.
> > There is another thread on this list which mentions the migration,
> > hopefully someone there is more informed.
> > Cheers,  
> >  Nemanja 


> >  
>   
>  The EMEA trac has many settings which aren't standard, so it is
> not a
>  normal migration like other tracs. Some of these settings are not
>  doable on pagure.
>  Not only it has FAS only access, but there should be also tickets
>  accessible per single FAS account. It should have even more particular
>  ACLs or defaults, so the question really is *how* we want to do it.
>  Mitzie should be trac admin, but I'm not sure, he can for sure help to
>  know all permissions and settings. 



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:


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


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.


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

[Robert Mayr]

Please take this as potential horrible reply too :)

2017-02-15 18:14 GMT+01:00 Brian Exelbierd <bex(a)pobox.com&gt;:

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


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


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


>  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)

[Brian Exelbierd]

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&gt;:
> > __ 
>
>   
>
>   
> > 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

[Robert Mayr]

2017-02-16 14:51 GMT+01:00 Brian Exelbierd <bex(a)pobox.com&gt;:

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


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


>  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).
Did you at least think about actual open tickets?


>  regards,
>
>  bex
>
>  
Kind regards.

-- 
Robert Mayr
(robyduck)

[Brian Exelbierd]

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&gt;:
> > __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

[Robert Scheck]

Hello Brian,

On Thu, 16 Feb 2017, Brian Exelbierd wrote:
>  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. 
I dislike the idea of making the process more complicated (e.g. by adding
yet another step). Could somebody explain why we are kind of abusing ticket
systems at this point rather looking for a single more appropriate software
(or alternatively by enhancing e.g. Pagure with the necessary features) to
serve needs of auditing, proper privacy, reporting, simplicity etc. in one?


Regards,
  Robert

[Zacharias Mitzelos]

I don't believe that having to open a second ticket and upload the
receipts there is so difficult or *so much time consuming* for the
Ambassadors, especially if it is going to be templated. That way the
"Funding requests" repository for EMEA will be public, and the other one
where you upload receipts will be private and visible only for
treasurers, regional card holders and the FCL. I agree that the repo
where you upload receipts needs to be as private as possible, as it
contains sensitive information.

Regarding the old trac, the tickets that are still active and need to be
transferred to the new repo in pagure are less than five (considering
that 2 tickets that fall under fiscal 17 will be closed this month). I
can even transfer those my self to the new repo in pagure and add a link
to the old ticket. I agree that the tickets from the old trac need to be
transferred to pagure and be visible if someone needs to check
something, that repo can be set to private (visible to everyone that is
in the EMEA-Ambassadors group in pagure - soon every EMEA Ambassador),
and read-only.

Since we have an EMEA-Ambassadors group in pagure, we can even create 2
repositories for tickets under this group, one for funding requests and
one for swag or other requests ( it's pretty straightforward to access a
repository in pagure once you visit the EMEA-Ambassadors group, so I
don't think that it will be confusing for someone).

Thanks,
Zach

--
Zacharias Mitzelos
<mitzie at mitzelos dot com>
mitzie on freenode
http://zacharias.mitzelos.com
GPG key ID: B345D18D

[Sylvia]

On Mon, 2017-02-20 at 18:10 +0200, Zacharias Mitzelos wrote:
>  I don't believe that having to open a second ticket and upload
> the
>  receipts there is so difficult or *so much time consuming* for the
>  Ambassadors, especially if it is going to be templated. That way the
>  "Funding requests" repository for EMEA will be public, and the other one
>  where you upload receipts will be private and visible only for
>  treasurers, regional card holders and the FCL. I agree that the repo
>  where you upload receipts needs to be as private as possible, as it
>  contains sensitive information.
>  
>  Regarding the old trac, the tickets that are still active and need to be
>  transferred to the new repo in pagure are less than five (considering
>  that 2 tickets that fall under fiscal 17 will be closed this month). I
>  can even transfer those my self to the new repo in pagure and add a link
>  to the old ticket. I agree that the tickets from the old trac need to be
>  transferred to pagure and be visible if someone needs to check
>  something, that repo can be set to private (visible to everyone that is
>  in the EMEA-Ambassadors group in pagure - soon every EMEA Ambassador),
>  and read-only.
>  
>  Since we have an EMEA-Ambassadors group in pagure, we can even create 2
>  repositories for tickets under this group, one for funding requests and
>  one for swag or other requests ( it's pretty straightforward to access a
>  repository in pagure once you visit the EMEA-Ambassadors group, so I
>  don't think that it will be confusing for someone).
>  
>  Thanks,
>  Zach
>  
>  --
>  Zacharias Mitzelos
>  <mitzie at mitzelos dot com>
>  mitzie on freenode
>  http://zacharias.mitzelos.com
>  GPG key ID: B345D18D
>  _______________________________________________
>   

I really like this and I don't think is confusing. Contrary, I think is
cleaner for everyone. 


Cheers,
Sylvia