Determining Use of OFN CC Funds (Co-budget)

International Community
1

Continuing the discussion from Strategies for funding the OFN Core OS project:

Hi all

For the April to June 2017 quarter, after much extended discussion and spreadsheeting pain, we managed to successfully fill the two OFN Core Commons technical buckets and get this reflected in co-budget. Yay everyone, but especially @MyriamBoure @lin_d_hop @danielle @serenity and me :slight_smile: See here:

This (as of this week) gave us a retrospective commons ‘technical’ funding bucket of $3,120 AUD. Revolutionary.

What We’ve Spent

At previous global hangouts I have raised the issue of deciding what this is spent on. The answer I have received is “Aus carries this so you decide” which is pretty much what we’ve gone with for this quarter. BUT:

  • It will not continue to be correct to assume that all the work done on this is done in Aus and we will need to work out how to handle that
  • Because there wasn’t actually agreed money in the buckets until very recently there has been a lack of clarity at this end about what should go where. I have spent a lot of time today wrestling with time trackers, spreadsheets and accounting packages and moving things around, mostly to
  • move things that (mostly @oeoeaio) had as ‘not billed’ into these now billable buckets
  • moving a couple of things that were support for funded projects out
  • I want to make sure those decisions are transparent so that they can be questioned, preferably with view to improving going forward rather than make me change anything for this quarter, which will cause me very much pain

I would loosely define my working assumptions as:

“These buckets are for making the open source development project environment be awesome, improving the quality of support and feedback for existing and new developers, and hence accelerating fabulous code contributions from everywhere”. Some early priorities identified have included: getting more devs through to ‘expert reviewer’ to open up the Aus bottleneck, including developing guidelines / checklists, tools for code quality etc. We have also put @maikel’s time supporting Transifex issues etc into these buckets. I have attached the Toggl report here in case anyone will get pleasure in reading even more detail than I have provided
Toggl_projects_2017-04-01_to_2017-06-30 (1).pdf (18.3 KB)

So the grand totals are:
Code Review & Merge: Budgeted $2,080; Spent $505; unallocated $1,575
Tech Oversight: Budgeted $1,040; Spent $1,050; overspent $10
Total: unallocated $1,565

What We Do With ‘Unallocated’ - for THIS quarter

Options for what could happen with this ‘unallocated’ $$:

  1. We could allocate more of the still ‘unbilled’ items to be paid out of core commons, for example I made a somewhat random decision to include some work on CodeClimate but not that on RuboCop
  • We could roll it over into the next quarter - so we have more to work with as it gets clearer what activities are clearly in. The July-Sept buckets are not fully funded yet so this is my preference
  • We could agree to cover activities that have been allocated for payment through ‘support’ buckets, where the code/PRs in question are clearly in the interests, and agreed priorities, of the whole community . . we can look at doing this for this past quarter but it will require some more fiddling at this end to get everything accounted for again . . revisit below . .

Opinions please . . . this is going to be lazy consent . . if I don’t hear from people I will go with Option 2. If you want Option 3, please reply including your proposed reallocation :slight_smile:

Proposed Future Spending

Once it was looking likely that there would be money in these buckets, there was an increasing number of suggestion / request / ideas for things that could be funded from them. I have been a pretty tight purse-master as it’s been really really hard to get money in there and the amount of things we could spend money on is infinite. It could disappear before we blink!

So in addition to the general guideline I used above for this quarter, I wanted to float a couple of ideas for a more open process for the next one. We could:

  • Gather and prioritise suggestions / requests for items to be paid for through these buckets. These could include:
  • Nominated activities that clearly fall in the ‘make better environment / community’ definition e.g. the day or so for @maikel to fully automate the translation stuff
  • Support e.g. code review and merge for items that are clearly tech debt or overarching priorities, even if the work has been prioritised / developer is being paid from within someone’s budget e.g. the work that was done on Paypal charging twice. Could things like this be nominated and agreed to be ‘subsidised’ by the Commons? UK / @lin_d_hop and France / @MyriamBoure may have a view on this . .
  • There may be some argument for some tech debt BUT it is so vast that these buckets are simply not equipped to go anywhere near it. I wonder if we could do something like:
    • actually set up a Tech Debt bucket (separate from and probably post-Spree Upgrade)
    • if/when there is money have the Dev Hangout/Mumble take responsibility for the tech debt pipe and prioritising spending and who does it
    • IN THE MEANTIME if the Dev HO/Mumble group identifies urgent and priority issues that they want dealt with, they can propose to the community that money from these CC buckets be used. What do people think? @oeoeaio @maikel @RohanM @enricostn @sauloperez @Matt-Yorkley @softgust @stveep etc!! Feel free to fork this off to a focused ‘how do we start getting progress on tech debt’ discussion . .

OK, I think there’s enough to chew on there. Sorry for the mountain of information (and especially those who’ve had me on multiple channels today) but I finally think I can see the light, so thanks for bearing with me!!

1 Like
Trialling Gitbook for User Guide . . YAY!
Is it possible to selectively 'notify producers' in an OC?
2

I’m a bit lost with all this information. I’m pretty new here and I don’t fully know how the funding really works.

That being said, option 2 seems the most reasonable, indeed. I see that spree upgrade will clearly need more funding to be finished so it falls in that July-Sept bucket.

If we actually set up a tech debt bucket it’d require a clear understanding of what tech debt needs to be address, being aligned with the product’s roadmap. I guess this is what you mean with

IN THE MEANTIME if the Dev HO/Mumble group identifies urgent and priority issues that they want dealt with, they can propose to the community that money from these CC buckets be used. What do people think?

3

Same here @Kirsten, Option 2 seems OK to me.

What I would like to see also is some discussion about the vision about the product. Once we have a more clear idea of that we’ll be able to spend money on development or other tasks focusing on a clear roadmap.

This is something we’ve been discussing during our meetings in Paris some week ago and want to share with everybody ASAP.

I’m just afraid that we spend our limited resources on development without a clear vision of where are we going. And I say that both regarding CC funds and instance funds.

1 Like
4

yes @enricostn I agree strongly about your point above. I think december with you and @lin_d_hop in Aus could be a good opportunity for some strong product architecture / direction planning , but I am also aware that that’s a long way away. I would really like to get a bit of a picture on what you’re thinking you guys need and how this fits with what @oeoeaio, @sstead and I have discussed (dreamed / planned) for the next generation of inventory management etc. I think that perhaps we need to find a way to have a product planning session remotely . . but would be great to hear what has come out of your face to face ouishare time ASAP!

1 Like
5

I love the conversation about vision - and maybe this isn’t the right time - or the right thread… But food enterprises here have asked me: Is the e-commerce/logistics platform the only tool, or does OFN have a vision of a tool box with multiple (perhaps linked, perhaps not) software tools that will help link, amplify, and strengthen food movements globally? For example - tools to help with advocacy (so things outside of market-based activity)? Tools to help with global planning and agenda setting ( I guess we have discourse for that now)? I’ve imagined, for example, that we might at least identify and curate other open source tools for some of these functions. The OFN global community is more likely to know about and evaluate these things, and then bring them to the attention of food movements using the OFN platform as a way to access them and link to them. Not sure this makes any sense but to illustrate: We all know that only selling things won’t change the world - we also need to collaborate on political actions. So what if, for example, when a customer checks out of an OFN shop, their order confirmation also links them to current poltical actions and advocacy projects that are going on in the local context. (All optional for the OC coordinator of course). So I might get a message like: We want to especially thank you for buying Legacy Greens’ products today. Legacy Greens is part of a provincial campaign right now to ban certain pesticides that we know are killing polliantors. They need your voice. — and this would have links to various campaigns underway… So for me there are 2 different parts to our visioning: how do we see the OFN platform/code per se changing in the longterm? and How do we see our OFN community linking with other oepn source tools/communities to expand our actions outside of the sales/markets arena?

1 Like
6

Just to expand on the idea above re: vision for future OFN environment and my interest in linking market + mission/movement for OFN users - see this US open source project - would there be a way to integrate some of their tools with OFN for example? I’ll be at a platform cooperativism meeting in September where they are presenting http://www.affinity.works/

1 Like
7

would be interested to know more about this - seems like it could be interesting

8

Hello, this is a request to spend core funds on a transifex improvement:

As @maikel notes:

This issue is suggesting a new tool to clean up our translations and ensure that we don’t mess things up with code typos. It would be a core commons contribution to work on this. Making i18n pull requests easier and faster for everyone.

9

@maikel @danielle - do we have an estimate on this?

10

I would guess 4 hours.

11

Hi again,

It would actually be wonderful to be able to complete the Rspec work that @Julius started here.

@enricostn and @sauloperez and @maikel how much time would you estimate would be required to finish this and merge it (including test and code review and merging it)?

1 Like
12

I don’t think we need QA testing in here as this is code only, but I’m not sure how much work is left here. It happened to have green CI once right @enricostn? did it have the usual amount of random failures or is it becoming even less reliable? If that’s the case I’d merge right away and work on the flaky tests individually. What do you guys think?

13

Missing specs to fix:

1) Spree::ShippingMethod#delivery? when the shipping method requires an address should be true

 Failure/Error: it { expect(shipping_method.delivery?).to be_true }

   expected true to respond to `true?` or perhaps you meant `be true` or `be_truthy`

 # ./spec/models/spree/shipping_method_spec.rb:96:in `block (4 levels) in <module:Spree>'

                                                                            

 2) Spree::ShippingMethod#delivery? when the shipping method does not require address should be false

 Failure/Error: it { expect(shipping_method.delivery?).to be_false }

   expected false to respond to `false?` or perhaps you meant `be false` or `be_falsey`

 # ./spec/models/spree/shipping_method_spec.rb:101:in `block (4 levels) in <module:Spree>'
14

These lines are not even there :scream: Something’s wrong with Travis CI or the branch :crying_cat_face:

15

can someone confirm whether the rspec issue should be considered as ‘nominated’ OFN CC work? @danielle @enricostn @sauloperez

1 Like
16

Hi everyone

See below for update on OFN CC funds spent in Jul-Sept 2017 quarter, as well as time tracker info on how this was spent

image.png755×161 5.16 KB

This means $1,474.4 underspend. Yay.

At the end of last quarter, we rolled the unspent $1,564 back into ‘available’ - and it was then allocated to Spree Upgrade, enabling Step 6 to get over the line.

Now that I have done these numbers @danielle and I are going to chat and propose a process for nominated / prioritising issues that could be dealt with through this. I have set up a project on github where issues can be put in as ‘nominated’ - https://github.com/openfoodfoundation/openfoodnetwork/projects/17. We will propose a process for prioritising next week and/or can pick this up in Dec (agenda getting very full!)

I would also like to flag that from where I’m sitting @enricostn and @sauloperez are picking up quite a lot of CC tasks, and we could consider sending a monthly / quarterly contribution their way too.

We could also put this money into the next Spree Upgrade bucket

Cheers
Kirsten

Time Q1 2018_2017-07-01_to_2017-09-30.pdf (26.8 KB)

1 Like
17

Thanks @Kirsten sorry I haven’t been following that conversation, started when I started farming :slight_smile:
I think one of our core common priority would be the automation on transifex process. I’m not sure this issue covers that https://github.com/openfoodfoundation/openfoodnetwork/issues/1549, and I don’t know at all what should be done, but maybe @enricostn @sauloperez and @maikel have an idea ? We discussed that with @enricostn some days ago and agreed that we needed that to be done…
Also I would suggest maybe to allow some CC on tech oversight on the data deletion work (anonymization of users, deletion of orders/users/entreprises after some time, etc.) OFFrance might contribute in paying some legal advisor so that we have some guidance here, but this is something which is core and concerns most instances I guess, right ? I’m not talking about the ux ability to delete things, but really the basic core capacility of delete stuffs.
Those would be my two priorities that are for me in the core CC scope.

18

I would say that the following issues are good candidates for CC:

  1. transifex process
  2. a first iteration of soft deletion (we can meanwhile ask some legal advice but I would start from deletion in UX instead of actual deletion)
  3. rspec upgrade

The order express my view on priorities also.

1 Like
19

It covers half of it. It would make sure that translations always end up in the next release, because they automatically appear on our to-do list. But it does not cover making new releases available for translation in Transifex. That would be a separate issue to tackle after the above.