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.
Do you understand my point or anything at all?
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?
Nice clarification Rachel.
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.
What do you think?
Sounds reasonable to me
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?
@danielle yes I will add it on the trello board.
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.
We only ever said we wanted 2 epics Rachel, not 3. I think you’re using the assumption that we wanted 3 to include the API line item?
Ah, yep, but only when there’s less s3 bugs. And the likelihood of that anytime soon is low
Nice discussion We definitely need to enable such instance specific integrations. I think we should limit local specific work to integrations, as we don’t allow that flexibility we put the whole community at risk. We are all fighting to make our users patient and say that if we don’t have it in OFN we can try to integrate, so IMO API maintenance and improvement should be a core and ongoing priority, it is not the same type of feature than other features IMO, as it allows flexibility and the ability for local instances to find workaround when global priorities are not aligned with local needs. So I tend to agree with @Rachel about a 4th priority column. But let’s discuss at global gathering