Last monthly hangout (I think) we started to talk about the idea that it was OK for instances with specific needs to develop something themselves as long as it didn’t required time and effort from the global team.
Example : setting up Zapier on a local instance. It helps doing stuff with the OFN plateform that does not involve the global team or hijack the global process.
So first of all I would like to be sure we are all aligned on this, as I don’t think I saw another discussion around this but maybe I’m wrong.
Then, if we agree on this, I think we need to work on the definition of “involving the global team”.
I would like to throw in a recent French case. We have users (hubs and producers) asking us to be able to use their bank payment system. This would enable them to use a payment system less expensive than stripe or paypal.
Our French community is so far linked to two banks: Crédit Mutuel and Crédit Coopératif. Those two banks have European partners/subsidiaries, but are still very local/French. Therefore I don’t think this will ever be voted in the global process.
If we hire a developer in France to integrate those systems, I believe we will have to deal with OFN’s API at least, which would then require the community to do code reviews I guess? So does this mean that this case cannot be handle otherwise than in the global process, or do we allow punctual contributions as long as they don’t required new development - only code review and test?
Thanks for raising this for clarification @Rachel. I also would like to know how we agree to proceed with these things. And, I feel OFN-CAN is at risk of missing a great party as we move forward on some of these instance-specific things. I understood before that - when we work with a global pipe - an instance doesn’t hire a developer to do some kind of code modification. Rache’s case is trying to separate an ‘instance developer’ from a ‘ofn global developer’ as I read it. Rachel asks (if I understand) what about if that ‘instance developer’ needs to interface with the ‘global OFN developers’ to accomplish the work they were hired for? (I think thats the question)
So I also want to ask - can the ‘instance developer’ be the same person as a ‘global ofn developer’ but working on their ‘non-OFN’ time? (specifically - if OFN-CAN wanted to do some zapping - can we pay someone on the dev team to do it - outside of their current global dev hours? Or do I need to find a new dev, not currently working with OFN so I don’t miss the party.)
I’m happy to support whatever we agree to - we just need to agree to something.
this is awesome and its awesome we are talking about it!
the global community should support it.
the only risk is that local instances will start to hire global devs to do this type of work and global pipe loses dev power…
agreed - and we should not let this happen. Global devs - IMHO - need to do global work as their priority hours. So we could just say that a local instance cannot hire a global dev who is already working 5 days/wk for global … or something like that.
I feel the same tension that @luisramos0 described. I totally understand the case you describe @Rachel and it makes perfect sense to me. We can’t forget however that what makes OFN awesome is the impact we have together and that instances having their own dedicated dev team is where we come from. IMO we should be very specific about the cases that make sense to tackle at instance-level. I think payment methods is one of them.
Having said that, an integration with OFN’s API will benefit us all and as such, I wouldn’t mind spending time code reviewing PRs that fix issues. IMO it is OFN’s global team duty to maintain and evolve the API with a clear vision. Others can then contribute to that plan as it fits their needs.
So if I understand you @sauloperez the decision as to whether or not instances take on a specific development project has to do with the nature of the work. This makes sense to me too. So what are your thoughts on this: - IF - a project is appropriate for local instance development (eg. localized payment methods needed) - is it OK for the local instance to engage (pay/barter…) directly with one of the global dev team members (as long as that person has time available to do the extra work) - or does the instance have to hire a local dev who is not part of the global team?
IMO I’d say that as long as that time isn’t being taken away from the time they have already committed to the global development pipe then having an existing dev do the work is a more efficient approach @tschumilas.
But getting dev time on top of the time they already dedicate is difficult. Which is then why those instances with devs have a distinct advantage - @Kirsten and @Jen and I can ask @maikel to do work on Aus specific stuff, @sauloperez is already doing stuff for Katuma, and @lin_d_hop and @Matt-Yorkley do stuff for the UK instance (e.g. set up Zapier, deal with instance specific bugs). France and Canada are at a definite disadvantage by not having devs connected locally to their instance.
You read my mind. I have the feeling that asking a core dev to work on an instance’s task my come at the expense of global time. But there are ways to fix it, I guess.
I think it’s completely legit if, for example, Canada paid Luis to setup custom zaps. We can all decide whom we are working for and I don’t want to introduce no-compete clauses because it doesn’t comply with our values of being open and collaborating.
I do share the worry that we lose dev power for the global pipe. @luisramos0 What kind of solutions did you have in mind there? We all need to be really aware of this risk and remind ourselves that it may be quicker and better to go through the global pipe. Maybe we need some room in the global pipe for these quick projects? Then there is no reason to hire one person if there is a global team that can work on the issue 24 hours a day and finish it quickly.
In the end, there are some tasks that always have to be done locally, like face-to-face customer support. That may include some custom reports or a sales pitch and fund raising. These roles are paid locally. So it’s impossible to do everything through the global pipe. The question is really about the distinction between local and global work. And that has to be done on a case-by-case basis.
I think it’s easier to hire and pay a local tech to do sysadmin and other jobs like wordpress, api clients, zapier integrations, etc. I think global dev skills are more difficult to find. Maybe I am wrong…
I think it just depends on the nature of the people running the local instance. While it might be easy for me to find tech people among my excolleagues and the local tech scene, it could be difficult for @tschumilas to find and talk to developers.
I understand sometimes it can be hard to communicate with them. We don’t have a perfect reputation on this
Just thought I’d throw in here… I can do the Zapier work and I can’t do the global dev work… so perhaps Zap needs could be directed to me (I have the capacity now) instead of taking resources away from the global dev team.
I agree with @lin_d_hop - to use our collective skill sets the most efficiently makes sense. Its like, I’m good at proposal writing - so I could help with that and take the load off someone with dev skills (not an exact comparision because we don’t pay for proposal writing out of the global pipe - I know, if we had more resources we likely would.) But the above discussion also says to me, that we should work toward having a dev in each instance as a longer term strategy. Maybe this wouldn’t be as necessary with a global instance - but thats a ways off.
Thank you all for your contributions!! I think it is safe to say that we all agree to the following:
some work will remain instance specific and need to be dealt with locally
we don’t want our global team to be distracted from the global pipe because of 1 (especially if each instance start to have a dev in its team - the temptation can be huge)
On the topic of who will take charge of point 1, I think we can decide this per case. I agree with you @sauloperez that it is not easy for everyone to find local dev power. However we have people in the community who are used to do the bridge (I think of this as a translator skill ). I for instance wouldn’t mind helping another instance find a dev for a specific thing. Because this is where I agree with @luisramos0 : it is more easier to find someone for something very specific (with an end date) rather than looking for long-term commitment.
But before going into these kind of details, let’s go a bit deeper on the definition of the type of work we would not pass through a global voting process. So let’s take my example of a local bank payment system. Like I wrote earlier, it’s pretty unlikely that this would be prioritize in our global voting process and all of our users don’t want to pay stripe’s high fees (point 1 check).
However, this specific work would lead to re-work our API and thus lead to take time from our global pot because of the code review. Does this mean that point 2 becomes unchecked and therefore we cannot go forward with this on a local level?
re your specific example, I’ll try the most simple solution:
I think if you have money in OFFrance to pay for that development, you should go ahead and pay for it all
OFFrance should pay for local dev and also should pay the global devs for the code review and api changes.
This would also be interesting for global OFN so the time that global dev team members are distracted from the global pipe (working and being payed by OFFrance) would be the pay off.
Even if we dont do this now, I think this is the end game.
The only thing I’d add to @luisramos0’s breakdown is the maintenance of the committed hours each week for the global pipe devs.
What I mean is there are a set of committed hours that each dev pledges when they become a contributor (do we track this somewhere?), that must be on average honoured. With this baseline in mind:
OFFrance has funding and wants to engage someone to do that work.
They get @sauloperez to do it.
Pau agrees to work an additional day a week specifically on this thing, and on top of his committed time for the global pipe.
OFFrance has funding and wants to engage someone to do that work.
They get @sauloperez to do it.
Pau agrees to work a day a week specifically on this thing, and he includes this as part of his committed time for the global pipe.
The thing I think worth talking about next is priority of this work within the global pipe (testing and code review) against the global priorities.
With our testing capacity very low I worry about having local instance things taking up space. And the code review column is always so full, adding additional things also concerns me. Yep, the instance pays for it, but it definitely takes velocity away from global priorities. And imagine if there were multiple local initiatives coming through at once…
So maybe we have to do these things:
Not allow for any local initiatives until we have the pipe down to 2 major global things.
Cap the number of local initiatives being done at any given time.
The final thing to think about is funding into the global pot. Right now, we’re running low. And my concern is still that funding that would have gone directly to the global pot will instead be redirected to local priorities. And maybe this is OK? But it needs to be hashed out a little more I think.
@Rachel shall we make this a topic for the global gathering in a couple of weeks?
Just a question @luisramos0 to be sure I understand: you think that all API changes need to be done by the core team and that external contributions cannot be imagined?
In that case I don’t think we can do that because it will for sure take some time off from the global pipe. Unless maybe we consider that API is a fixed thing in our pipe, such as bug, techdebt and epics. So our dev-ready column would look like this:
2 epics
3 bugs
5 tech issues (tech debt and sys admin)
2 API issues (instead of 3 epics)
Just a thought. That would be IMO the only way to keep our API moving on without being too local specific. What do you think?
I dont think API changes must be done by global devs, that was just the most simple example I could think of. External devs and local devs and all other contributors, can make changes to the API.
I’d not complicate the columns because of API. imo “API is a feature” so it should be together with epics.
). I for instance wouldn’t mind helping another instance find a dev for a specific thing. Because this is where I agree with 
