Community devroom
Contributing (with) civil servants
How government and public sector open source projects and contributors are different from individual and corporate ones.
The open source is getting mature and there are a lot of established ways of behavior, expectations even, that both contributors and maintainers of a codebase have. Some of these expectations are explicit in contributing files, whereas others are implicit and more of a cultural behaviour we as a group have taken on over the years. Governments and civil servants come from a very different background and when they start developing publishing software in the open under a free licenses, these cultures may meet, and sometimes even clash. We know that individual volunteer contributors differ from corporate contributors, how do public workers as contributors fit into this.
How public workers contribute has to do with how they operate, and how the society expect them operate in other fields of their operation. If not understood properly, this can lead to frustration of a FOSS contributor who want to make a useful contribution to a codebase developed by a public organization. In this talk we will try to give you the tools and the mindset that will help you succeed when submitting those merge requests.
"As a volunteer I am making contributions to a codebase managed by a public organization and it's behaving differently than the FOSS I am used to and here is why and how to adapt."
Additional information
| Type | devroom |
|---|
More sessions
| 2/7/21 |
Management is difficult even under the best of circumstances and managing globally-distributed teams is even more so. With the global COVID-19 pandemic and the restrictions it forced on all of us, management is nothing like the best of circumstances. With the pandemic, suddenly everyone is a remotee – even people who have no experience in working remotely, and no desire to work in such an environment. In this talk, I’ll explore how the lessons learned from navigating a globally-distributed ...
|
| 2/7/21 |
During this talk, you'll learn about topics like cross-cultural collaboration, giving and receiving feedback, and active listening -- all things that are vital to the health of our open source communities.
|
| 2/7/21 |
What do you do when the interest of your different constituencies are in conflict? Who do you favor and why? The 4 Freedoms and the OSD were designed for a small community of hobbyists. They offer little help when it comes to addressing the challenges open source faces today. Does open source need a W3C-inspired "priority of constituencies?" In this talk we’ll dig into the priority of constituencies, see how it could apply to open source, and get some interesting insights out of doing so.
|
| 2/7/21 |
Even a large Open Source project is at risk to have a too internal focus. Listening to users does not come by itself. This presentation describes the logic behind the user engagement of the MariaDB Foundation, which has been complemented during 2020 by "MariaDB Server Fests", virtual events reaching nearly 20.000 users.
|
| 2/7/21 |
It is impossible to bring every idea, every innovation, and every improvement you can think of to fruition. Doing a little less allows you to honor the finite amount of time each person can give to your cause or project or workplace. But how do you start cutting those todo's down to a manageable level?
|
| 2/7/21 |
Open-source software is code that is designed to be publicly accessible. Open source has core principles that make it rely on collaboration between contributors and companies in order to achieve a common goal. To attain more collaborations, onboarding in most open source communities should be considered a priority. Oftentimes, beginners who are new to open source projects develop cold feet a short while after joining a community because they are not properly onboarded into the community. ...
|
| 2/7/21 |
We often see many open source projects struggle with maintaining quality documentation and finding contributors who are interested in helping with project documentation. There are several reasons for this, such as many viewing documentation as a separate product from code or a belief that people will be able to make sense of what the code is doing by reading the code. For these and other reasons, documentation work is often done at the last minute and done by people with low motivation and ...
|
