joshuaboniface
/
blog
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

More wording cleanups

This commit is contained in:
Joshua Boniface 2022-12-07 16:48:14 -05:00
parent 35edb2a7e4
commit d2ca728a4a
1 changed files with 1 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
content/problems-in-floss-3.md
View File

@ -81,9 +81,7 @@ In the Jellyfin project, we have a relatively small number of core "server" deve
In this situation, "the commons" is the codebase as a whole.
The tragedy comes because there is a conflicting incentive for the user-developer-turned-new-contributor. Without saying anything about their actual skill level, it is a lot more work for them to (a) get up to speed on the codebase, *and* (b) learn the rules and processes of the project, *and* (c) ensure that their code follows the often-institutionalized-and-undocumented knowledge practices that the current contributors have developed, all on top of the work of actually implementing the feature.
Thus, there is incentive for the user-developer to implement the feature they want quickly, so they can use it, without too much concern for how it fits into the larger codebase (the "commons" of the project).
The tragedy comes because there is a conflicting incentive for the user-developer-turned-new-contributor. Without saying anything about their actual skill level, it is a lot of work for them to (a) get up to speed on the codebase, *and* (b) learn the rules and processes of the project, *and* (c) ensure that their code follows the often-institutionalized-and-undocumented knowledge practices that the current contributors have developed, all on top of the work of actually implementing the feature. However, there is incentive for the user-developer to implement the feature they want quickly, so they can use it, without too much concern for how it fits into the larger codebase (the "commons" of the project).
This can have two effects, both of which are alienating: first, if the project "doesn't care" about "the commons", you can end up with a situation where cleanup work is discarded, the codebase becomes messy as new contributions add code-paths that do not align with the structure, and this alienates those developers doing the cleanup; or, second, if the project *does* "care" about "the commons", this can alienate the new user-developer, who sees the constant requests for rewrites as "nitpicking" their contributions, alienating them and making them at best less likely to see their contribution through, and at worse cause them to fork and implement things their way.