TODO Guide Employee Open Source Engagement Guide - Principle 4: Has Transparent Motivations

[jlprat]

Issue to track progress of the Principle: Has Transparent Motivations.

[jlprat]

Some of the things that I think we should reflect here:

• Be open about your affiliation: We kind of touched this on the first principle, but this should be also present here.
• Share level of commitment for the project: is it a "one off", is it a long or mid level commitment?
• Purpose of the collaboration: what is the the work you are willing/allowed to take? Is the purpose to help the community taking tasks that affect all the community? Or only the intersection between community and their company's interest?
• Be straightforward: you shall not have any hidden agenda or trying to "secretly" steer the project in certain direction

[juliaferraioli]

If this isn't too detailed -- in your commits, always use the email appropriate to the context. That is, if you're making a contribution as part of your job at company xyz, you should be signing it using person@xyz.com. I go into more detail: https://www.juliaferraioli.com/blog/2022/your-git-email-matters/

[jlprat]

I think we should totally add this @juliaferraioli :)

[jlprat]

An attempt to convert the bullet points to text:

Your work on the projects should be transparent. Transparency has many different aspects an dimensions that we will try to showcase here.
You should be transparent with the rest on the community about your level of commitment with this project: from working only on issues that overlap with your company's interests, to help out in anything the project needs, or anything in between. All the options are valid and there is not right or wrong answer.
It is important to be transparent about the reason why you are working on the tasks you pick. Sharing as much context as you can is useful for the rest of the community to better gauge the importance of the work and why it should be included in the project. This is not about revealing company strategies, but sharing and explaining why is this paritcular piece of work needed and interesting.
We have multiple hats when interacting with communities: our company's or our own. It is important to differentiate and be explicit about which virtual persona you are in each moment. For example, when committing changes or writing emails, use the corporate or the personal email accordingly.

[jzb]

An attempt to convert the bullet points to text:

You should be transparent with the rest on the community about your level of commitment with this project: from working only on issues that overlap with your company's interests, to help out in anything the project needs, or anything in between. All the options are valid and there is not right or wrong answer.

I'm curious what this would look like in practice. Any examples? I often see people stating when they'll be out of pocket as long-time contributors but less so people giving levels of commitment up-front.

[jlprat]

For example at Aiven we have people whose purpose is to contribute to specific Open Source projects, so people can have a long commitment to the projects. Making this known to the communities helps in planning, sharing responsibilities, and helps building trust.
I would guess sporadic collaborations are the default.
Other companies might say, we want this set of features on this project and we want to help make it happen and they dedicate some people on such endeavors, when finished, people focus on other projects.

Is this what you were looking for?

[cornelius]

See #384 for a draft for the guide based on the input of the issues.

[alice-sowerby]

Closing as all additional input has been received.