In-Project Education
Educating project members is important to establish a shared knowledge base on both technical aspects but also on some of the skillsets that might not be native to FLOSS projects. Also, learning by doing is a strong motivator for many FLOSS contributors and as such design needs to be spread as much as it can within projects where its needed.
Several of the project members argued that best practices are taken into account when implementing code, and here educational conversations are taking place.
For instance one participant said that “[name removed] is much more experienced than me. So normally it’s him educating me about, you know, a better way to do something. But that’s alright. I feel that that’s really good.” (Interview, Jellyfin)
This quote seems to indicate that it’s not necessarily code quality or similar technical aspects being discussed and taught in the project. However it does seem that design discussions are predisposed to be more subjective and routed in the contributor in question’s own view on the matter. One such example comes from one of the primary contributors on the android client that recounts a discussion regarding how notifications were handled with regards to music (Interview, Jellyfin). Here he describes that while music is playing the corresponding notification should not be removable which made sense for him both from a logical standpoint, but also due to the fact that this design decision was mentioned in Google’s material guidelines. Regarding the more technical aspects, in-project education is also mentioned by several contributors in some shape or form.
Many of these findings from the interview mentioned a constant back and forth and discussion on features, problems and the like in different ways and at different times. One such quote is the following from a contributor regarding his experience with people asking about the inner workings of the different projects.
He said that “there is a lot of that sort of back and forth between people, but like someone will come in and be like, ‘hey, I’m not really sure how this works or how that works’. And there will usually be a couple of people who do know how it works.” (Interview, Jellyfin).
This is also touched upon when a contributor said that he “get[s] a lot of help in these parts. And well, I kinda think that it also helps us with doing things correctly.” (Interview, Jellyfin). This notion of doing things quote-on-quote ‘correctly’ seems to be prevalent in the project, especially with regards to making sure that the code that is merged into the main branches is of high quality. Yet, it does seem that design decisions are subject to more discussion and in general it seems that contributors are likely to foster strong opinions on the design choices even though it allegedly is not their strongest suit. This however ties into the general perception of design decisions and will be discussed in the section aptly named “Perception of design in FLOSS projects”.
Discuss
Summary
- Make time for in-project education between community members, project members and the like.
- It is not only important to align a project towards its common goal, it is also motivational to learn and have good experiences doing so.
- Design decisions take more time, and the education surrounding it is largely self thought in the projects.
- The few people in FLOSS projects, if any, that have knowledge on any design related activities needs to spread the knowledge actively in the project.
- Doing this might be tricky in practice. How does one best educate fellow project members?