Thank you @Kirsten, I suggest we use cobudget, to start with, for what concerns the “shared global tasks” or cross-instances tasks:
- projects: new features developments that are multi-instances projects and are funded by various instances & people. Or more generally we could say projects that have a positive structural impact for various instances. Like ideally if @CynthiaReynolds develops a super communication tool to explain the positive impact on OFN multiple instances could contribute in funding that tasks it’s a project, not ongoing.
- structural tasks: that are done for the global community: code review and merge for non funded projects and volunteer contributions in code, community facilitation, support to new instances, … those are more ongoing tasks, not project based
I suggest we create one bucket for each cross-instance project and one bucket for each structural tasks, and that we make transparent what is funded when it’s already done. Even if there is no funding yet, we can open an idea bucket so that we raise consciousness that those tasks should be valued at some point I’m thinking especially in community facilitation for example or non dev tasks which are not funded yet.
We should I think just be clear about what goes into a project and what goes into an ongoing cross-instance task.
After your response @Kirsten I suggest that we include in the project the time and budget corresponding to code review and merge for the project, it’s a direct cost of the project. AND that would be awesome if projects could also give back a small amount to finance other ongoing structural costs (if enough fundings of course)… We could decide to set up a % (10 to 20%?) for projects that would cover the code review and merge and a small amount for other ongoing structural tasks. So if the dev work is estimated to 1000, the co-budget bucket should be set up to 1150 for example, and the 150 finance first code review and merge, and if money remains, it can be transferred to another bucket for ongoing tasks. (this is an example of process, but please make other suggestions!)
For example for VAT overhaul, I will create a bucket on co-budget, and in the amount I will put: the work done by Rob & me to find out how to implement that, the work by Rob for estimation, the work needed in actual development, and the work of code review and merge, and testing + we could add a little to contribute to ongoing tasks (depends on funding possibility! Of course some of it can also be volunteer if people agree to, like I do for tax). In the amount set up on a bucket the objective should be to try and fund correctly the projects so that we don’t burnout people on the way and we manage through funded projects to put a bit of money aside to finance the community development So ideally we should think not only on dev tasks, but also all the organization and facilitation tasks that today are mostly not funded.
BUT we also need to abound in a fund that enable to review and merge pieces of code for contributions that are not funded or for new instances/developers just starting to enter the process of contribution to code. So this would be more a structural tasks, like we can propose to finance collectively one or two days per months to pay the people who do that for the collective (I’m not sure if that is already funded today indirectly by Australia, or if done on a volunteer base by the Aussie core dev, or if it’s just not done and nothing is reviewed and merged if not funded… this is not clear to me)
So we can have a bucket “code review and merge”, “community facilitation”, “international development support”, “global website”, etc. and set them up to 0, 1 or 2 days per month for example, as we consider that for the next 6 months we would like to be able to finance for the new instances who have not yet funding or for random contributors who would submit pieces of code without being funded (volunteer contributions) so that they code be reviewed and merged.
In OuiShare we do that a bit the same way, we have projects and global ongoing tasks, so every year in November, we raise buckets for the ongoing tasks for next year, so that people can know that they are going to be paid to do this or that (like to do community facilitation equivalent 1 day per week) for the next year. For projects buckets can be raised anytime.
We use the same cobudget space for global projects and structural costs AND for national projects and structural costs, we have just used FR when the bucket only concerns French projects or ongoing tasks, ES for Spain, etc. So it enables also every local instance to work with open budgeting and crowdfunding within their local ecosystem. And it enables transparency within the whole community.
Also other input from my OuiShare experience, OuiShare France who created OuiShare is still after 4 years financing most of the global ongoing tasks, even if there are communities in 30 countries. Now that communities in Spain and South America starts to structure and organize projects that brings money in they are going to contribute also from next year. Maybe we will manage in OFN to distribute quicker the financing of the global tasks, but I know it’s not easy, and it takes time.
So for example Kirsten you put 10K in cobudget in June, maybe you will allocate 6K to a cross-instance project (like standing orders) but maybe some of the money were used to pay for Rohan’s or Rob’s time to do estimates or code review for other instances not yet funded, so for example 2K maybe will reflect that in the bucket “Code review and merge” and maybe you have 2K remaining that you can decide to allocate to a project or an ongoing task when you want. So we will see clearly the contributions from each instance to support the development of the global community, either through projects or ongoing tasks.
Ongoing tasks might work first on a base: "if there is money cool we can do stuff, else find a way either to raise money or find people who agree to do that on a volunteer base." We’ll see when we have more money if we can have 3/6 months missions with some paid days of work for those ongoing tasks.
I would suggest that we avoid counting the volunteer contributions of people like put an hourly rate on people time doing things on a volunteer base and put that in co-budget as a founding. Like if I start counting my time and putting a hour rate one my time, if Rohan, Kirsten, Danielle, if we all start doing that I’m afraid we start counting every time we spend two hours answering messages, like I just did for this post. If we want to give light also to volunteer contributions and value them we can think about how to do that but I suggest we don’t start with that in co-budget.
I suggest we put the email address of the people who represent an entity who could potentially contribute, even if the amount is 0 for the moment in contribution so that you can still have look at what happens on co-budget and get used to how it works. Like @JozeHladnik for example it’s not because you have no funding yet that you can’t be into co-budget, you will have 0 to spend, that’s all.