Clarifying review process for new contributors #576

New Issue

basebuilder · 2024-02-21T11:09:05Z

basebuilder commented

2024-02-21 11:09:05 +00:00

As far as I understand it, contributions can be grouped into two meaningful categories:

Free Contributions
Paid Contributions (as per Resolution 003)

While the text in Resolution 001 explains passing resolutions at higher level relating to all types of resolutions, it does not address specifically processes of doing Paid Contributions so I read through other resolutions and docs, but I don't see anything specific here. Perhaps I missed it.

Is there a threshold or quorum for review of "satisfactory work" when contributions are attached to sending invoices for members and non-Federation contributors?

For new contributors (such as myself) I think it would be helpful to have a more clear process of approval stated somewhere.

As far as I understand it, contributions can be grouped into two meaningful categories: - Free Contributions - Paid Contributions (as per [Resolution 003](https://docs.coopcloud.tech/federation/resolutions/passed/003/)) While the text in [Resolution 001](https://docs.coopcloud.tech/federation/resolutions/passed/001/) explains passing resolutions at higher level relating to all types of resolutions, it does not address specifically processes of doing *Paid Contributions* so I read through other resolutions and docs, but I don't see anything specific here. Perhaps I missed it. Is there a threshold or quorum for review of "satisfactory work" when contributions are attached to sending invoices for members and non-Federation contributors? For new contributors (such as myself) I think it would be helpful to have a more clear process of approval stated somewhere.

basebuilder added this to the Improvements to Websites milestone 2024-02-21 11:09:05 +00:00

basebuilder added the

question

documentation

proposal

labels 2024-02-21 11:09:05 +00:00

basebuilder referenced this issue

2024-02-21 11:09:56 +00:00

Track Progress of Resolution 014: Budget 008: Critical Fixes - 2023-12-06 #547

decentral1se commented

2024-02-22 23:06:56 +00:00

Thanks for raising, much appreciated!

Is there a threshold or quorum for review of "satisfactory work" when contributions are attached to sending invoices for members and non-Federation contributors?

Can you explain further what you mean here?

Do you mean getting paid for work that isn't in a budget which is passed through the decision making process?

Thanks for raising, much appreciated! > Is there a threshold or quorum for review of "satisfactory work" when contributions are attached to sending invoices for members and non-Federation contributors? Can you explain further what you mean here? Do you mean getting paid for work that isn't in a budget which is passed through the decision making process?

decentral1se referenced this issue

2024-02-22 23:09:49 +00:00

Track Progress of Resolution 014: Budget 008: Critical Fixes - 2023-12-06 #547

basebuilder commented

2024-02-23 10:50:23 +00:00

At present I was approved (in issue comments and Matrix chats) to some small portion (up to 8 hrs) of Resolution 014: Budget 008 for specifically task #537 and only that task. This issue is not about that.

I was also given push access to main branches, so I can basically just do what I think is sufficient, push to main call it a day, and send my invoice. I think for ppl who have been involved with a project since inception and made prior contributions that person learns a sense of what is sufficient. However, as a newcomer I wanted to tread lightly, put things in granular pull-requests, wait for feedback, and ideally get someone who's been around longer to merge so that my contribs are all in line with the M.O. Overall I received positive comments and emojis, so I think my contributions were well received.

To explain what I mean by "threshold or quorum for review" is that in many open-source projects there is often the practice only lead devs can merge into main and on GitHub there is the Review feature and you can set thresholds like Requires approval from 2x reviewers being merging is possible.

Do you mean getting paid for work that isn't in a budget which is passed through the decision making process?

No. I found Resolution 003 & 004 to be perfectly clear and great about budgets being allocated. But rather my proposal is that Co-op Cloud should codify a clear feedback process for review and approval of contributions. I think this could/should be the same for non-paid and paid contributions alike.

At present I was approved (in issue comments and Matrix chats) to some small portion (up to 8 hrs) of `Resolution 014: Budget 008` for specifically task #537 and only that task. This issue is not about that. I was also given push access to `main` branches, so I can basically just do what I think is sufficient, push to `main` call it a day, and send my invoice. I think for ppl who have been involved with a project since inception and made prior contributions that person learns a sense of what is sufficient. However, as a newcomer I wanted to tread lightly, put things in granular pull-requests, wait for feedback, and ideally get someone who's been around longer to merge so that my contribs are all in line with the M.O. Overall I received positive comments and emojis, so I think my contributions were well received. To explain what I mean by *"threshold or quorum for review"* is that in many open-source projects there is often the practice only lead devs can merge into `main` and on GitHub there is the `Review` feature and you can set thresholds like `Requires approval from 2x reviewers` being merging is possible. > Do you mean getting paid for work that isn't in a budget which is passed through the decision making process? No. I found `Resolution 003 & 004` to be perfectly clear and great about budgets being allocated. But rather my proposal is that Co-op Cloud should codify a clear *feedback process for review and approval of contributions*. I think this could/should be the same for non-paid and paid contributions alike.

3wordchant commented

2024-02-26 19:08:27 +00:00

@basebuilder if you're asking about how work against a specific Budget is decided to be "sufficient" then it's currently up to whoever is listed on the specific Budget, e.g. Resolution 011 Budget 005 it'd be up to "Calix/3wc, decentral1se, Philipp and Moritz" whether another contributor can help, and when their work is complete.

Building on @decentral1se's "Do you mean getting paid for work that isn't in a budget which is passed through the decision making process?", currently the only mechanism for paying for ad-hoc contributions (i.e. those not specifically budgeted) is Resolution 010 Budget 004 "critical fixes".

That is, an issue which isn't a "critical fix" as defined by Resolution 010, and isn't part of another Budget, currently isn't eligible for payment.

Not sure if this is answering your question, further clarifications welcome!

@basebuilder if you're asking about how work against a specific Budget is decided to be "sufficient" then it's currently up to whoever is listed on the specific Budget, e.g. [Resolution 011 Budget 005](https://docs.coopcloud.tech/federation/resolutions/passed/011/#details-budget-005) it'd be up to "Calix/3wc, decentral1se, Philipp and Moritz" whether another contributor can help, and when their work is complete. Building on @decentral1se's "Do you mean getting paid for work that isn't in a budget which is passed through the decision making process?", currently the only mechanism for paying for ad-hoc contributions (i.e. those not specifically budgeted) is [Resolution 010 Budget 004 "critical fixes"](https://docs.coopcloud.tech/federation/resolutions/passed/010/). That is, an issue which isn't a "critical fix" as defined by Resolution 010, and isn't part of another Budget, currently isn't eligible for payment. Not sure if this is answering your question, further clarifications welcome!

basebuilder commented

2024-02-27 12:57:57 +00:00

Please forget that I made this separation of paid and non-paid work and referenced things I have been working on- this is not about that.

At present, there is no a clear review process for things being merged in. Early on I was given write access to all the site repos. I felt hesitant to just merging in things, especially more drastic UI / UX changes to the Docs site. As I said in my last comment:

... in many open-source projects there is often the practice only lead devs can merge into main and on GitHub there is the Review feature and you can set thresholds like Requires approval from 2x reviewers being merging is possible.

I feel like this is a pretty clear, straight-forward proposal towards a establishing a review process for new contributors

"Do you mean getting paid for work that isn't in a budget..."

This is only relevant in the fact the quality of contributions we aim for (and method of them being merged in) should be the same regardless of paid / non-paid work.

Please forget that I made this separation of paid and non-paid work and referenced things I have been working on- this is **not about that.** At present, there is no a clear review process for things being merged in. Early on I was given `write` access to all the site repos. I felt hesitant to just merging in things, especially more drastic UI / UX changes to the Docs site. As I said in my last comment: > ... in many open-source projects there is often the practice only lead devs can merge into main and on GitHub there is the Review feature and you can set thresholds like Requires approval from 2x reviewers being merging is possible. I feel like this is a pretty clear, straight-forward proposal towards a establishing a *review process for new contributors* > "Do you mean getting paid for work that isn't in a budget..." This is *only* relevant in the fact the quality of contributions we aim for (and method of them being merged in) should be the same regardless of paid / non-paid work.

decentral1se commented

2024-02-29 09:27:41 +00:00

Righto, clear!

The only hesitation I have about setting up review requirements is that there aren't very many active folks atm. I try my best to review and be responding but I also have my limits. For example, the abra release is blocked partially due to my unavailability.

So, if we set up this review structure, which I'm not against, then we also have to have a way to fall back to "nobody is around, just gooooo".

While it may look like "no clear review process", the current way things work is informally based on my experiences and understandings of C4 https://hintjens.gitbooks.io/social-architecture/content/chapter4.html and the idea of optimistic merging. This could be written down somewhere but it isn't atm.

Righto, clear! The only hesitation I have about setting up review requirements is that there aren't very many active folks atm. I try my best to review and be responding but I also have my limits. For example, the `abra` release is blocked partially due to my unavailability. So, if we set up this review structure, which I'm not against, then we also have to have a way to fall back to "nobody is around, just gooooo". While it may look like "no clear review process", the current way things work is informally based on my experiences and understandings of C4 https://hintjens.gitbooks.io/social-architecture/content/chapter4.html and the idea of optimistic merging. This could be written down somewhere but it isn't atm.

👍 2

decentral1se referenced this issue from a commit

2024-03-27 05:55:25 +00:00

docs: contributing guidelines

decentral1se commented

2024-03-27 05:56:00 +00:00

Made a start on 45446f0168 and given the 👍 count on the previous comment, maybe that is enough? Change/re-open if you feel otherwise!

Made a start on https://git.coopcloud.tech/coop-cloud/docs.coopcloud.tech/commit/45446f0168778601f82827cc1d0cdbc73e394a2e and given the 👍 count on the previous comment, maybe that is enough? Change/re-open if you feel otherwise!

👍 1

decentral1se closed this issue

2024-03-27 05:56:00 +00:00

Sign in to join this conversation.

No Milestone

No project

No Assignees

3 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/organising#576