Mention that paid work gives no privileges? #108

matkoniecz commented 2025年07月19日 12:13:32 +02:00

So if someone did PR as paid work they are not entitled to priority review. (so ideally grant would be formed in way that gives ample time to review or merging is not strictly required).

And if anything, paid work would come with expectations of higher quality (issues pointed in PR review fixed by author etc)

So if someone did PR as paid work they are not entitled to priority review. (so ideally grant would be formed in way that gives ample time to review or merging is not strictly required). And if anything, paid work would come with expectations of higher quality (issues pointed in PR review fixed by author etc)

mnalis commented 2025年07月25日 16:17:03 +02:00

So if someone did PR as paid work they are not entitled to priority review

Generally in any FOSS project, I would assume that there is no entitlements for priority review for anyone, unless the reviewer explicitly stated so (e.g. in exchange for money or whatever reason on a per-case basis).
But sure, it does not harm to spell it out specifically!

And if anything, paid work would come with expectations of higher quality (issues pointed in PR review fixed by author etc)

That sounds reasonable to me - if you're being paid to do the work, then you should be the one doing the work, and not offloading it to maintainers.

> So if someone did PR as paid work they are not entitled to priority review Generally in any FOSS project, I would assume that there is **no** entitlements for priority review for anyone, unless the reviewer explicitly stated so (e.g. in exchange for money or whatever reason on a per-case basis). But sure, it does not harm to spell it out specifically! > And if anything, paid work would come with expectations of higher quality (issues pointed in PR review fixed by author etc) That sounds reasonable to me - if you're being paid to do the work, then you should be the one doing the work, and not offloading it to maintainers.

pastk commented 2025年07月25日 18:10:49 +02:00

Surely paid work is more about extra responsibilities rather than privileges :)

Otherwise who would do the volunteer work? :)

Surely paid work is more about extra responsibilities rather than privileges :) Otherwise who would do the volunteer work? :)

pastk commented 2025年07月25日 18:14:01 +02:00

Re reviewing specifically - if a particular chunk of work is planned to be paid for then why it should be about coding expenses only? It makes sense to include review, testing, design etc. expenses into the package.

Re reviewing specifically - if a particular chunk of work is planned to be paid for then why it should be about coding expenses only? It makes sense to include review, testing, design etc. expenses into the package.

mnalis commented 2025年07月26日 18:59:07 +02:00

It makes sense to include review, testing, design etc. expenses into the package.

Yes, I agree that paid PR authors should do not just the writing but design and testing; but I think what was meant here by "review" is specifically "maintainer PR review", i.e. activity the project maintainer(s) themselves must do before they click "merge" button. There will hopefully¹ always be some effort involved there.

Also, even in best of cases, review should always be done by some other person then the one who wrote the code -- there is not (much) use in self-reviewing. If one didn't see the issue while they were writing the code, it is less likely that they'll see the issue when looking at their own code afterwards. You need an extra pair of eyes there.

Of course, PR writers should always strive to write good code in readable fashion and minimize the load on maintainers and implement any changes that they may request as best as possible; but in practice PR authors are sometimes not very good at that, and maintainers are known to often step in and finish the work instead of insisting on more back-and-forth.

So I think idea here is that such behaviour (of writing good and readable code and minimize work of maintainers) should be not just a nice etiquette, but explicitly required to be of the highest standard in cases when the authored is being paid to write the PR (instead of paid PR authors intentionally being lazy to minimize work required on their part).

---

IOW, what is "it would be nice if you could do xyz; but it it is too hard, let me know and I'll do it myself" comment from maintainer for volunteer PR contributors should become more of a "you must do xyz" for paid PR contributors.

> It makes sense to include review, testing, design etc. expenses into the package. Yes, I agree that paid PR authors should do not just the writing but design and testing; but I think what was meant here by _"review"_ is specifically _"maintainer PR review"_, i.e. activity the project maintainer(s) themselves must do before they click "merge" button. There will _hopefully_[^1] always be some effort involved there. Also, even in best of cases, review should _always be done by some other person_ then the one who wrote the code -- there is not (much) use in self-reviewing. If one didn't see the issue while they were writing the code, it is less likely that they'll see the issue when looking at _their own_ code afterwards. You need an extra pair of eyes there. Of course, PR writers should always strive to write good code in readable fashion and minimize the load on maintainers and implement any changes that they may request as best as possible; but in practice PR authors are sometimes not very good at that, and maintainers are known to often step in and finish the work instead of insisting on more back-and-forth. So I think idea here is that such behaviour (of writing good and readable code and minimize work of maintainers) should be not just a nice etiquette, but explicitly required to be of the highest standard in cases when the authored is being paid to write the PR (instead of paid PR authors intentionally being lazy to minimize work required on their part). --- IOW, what is _**"it would be nice if you could do xyz; but it it is too hard, let me know and I'll do it myself"**_ comment from maintainer for **volunteer** PR contributors should become more of a _**"you must do xyz"**_ for **paid** PR contributors. [^1]: i.e. we do not want people with commit rights accepting random code into `master` unless they've given it _at least_ a cursory look; it would be horrible from both security and code quality perspective is absolutely no effort went into merging PR.

pastk commented 2025年07月26日 19:11:23 +02:00

Yes I meant reviewing by other people / maintainers exactly.

I.e. if a feature have been paid for then why its supposed to be only one person doing the work (and being paid)?
I.e. usually its better to have a team of designers, testers, coders (in our case its often cpp, android and ios), reviewers, etc.

Yes I meant reviewing by other people / maintainers exactly. I.e. if a feature have been paid for then why its supposed to be only one person doing the work (and being paid)? I.e. usually its better to have a team of designers, testers, coders (in our case its often cpp, android and ios), reviewers, etc.