Inbound Contributions

[cornelius]

Here are some thoughts about the different kinds of views on contributions which can be considered and be covered by processes within an organization:

In most cases the majority of contributions an organization will do are outbound contributions where the destination is an open source project which is run by another organization, for example an open source foundation. So the process has to cover questions such as how to legally make a contribution on behalf of an organization, how to review licenses, sign CLAs, etc.

When an organization is running open source projects itself, there is another dimension to consider, how inbound contributions are handled, i.e. contributions which are coming from other organizations towards an open source project. So the perspective is from the other direction.

While some aspects are the same, such as how to legally make a contribution under an open source license, other aspects are different, mainly because the organization doesn't have to process the conditions of an external open source project, but is setting this condition itself on the open source project it runs. So instead of a process for reviewing a license a process to choose a license is needed, instead of a process how to sign CLAs, a process is needed which decides wether to set a CLA or some other mechanism, etc.

Not sure, what the best way is to represent these different aspects, maybe as a set of optional requirements which are only applicable when running own open source projects?

[gkunz]

Hi Cornelius, thank you for summarizing this. I had very similar thoughts during the kick-off call.

I don't have a strong opinion (yet) on how and where to include these aspects, e.g., in a combined or a separate contribution spec, but I very much support the idea of considering them somewhere. Maybe it helps to continue collecting additional requirements and then based on the overall picture decide on how to structure the specs.

In general, I would argue that we could consider an extended process for i) creating and ii) running open source projects. In addition to what you mention above, this process could include requirements such as (in really random order):

• outlining the strategic value and direction of the project and aligning this with the business strategy
• determining potential support activities (marketing, devrel, presentations)
• determining that the repository includes all required information (contribution guide, license, security policy...),
• outline (and implement) a desired project governance model
• determining if a project should be "self-hosted" or donated to a foundation
• ...

Aiming for a high-level specification, we don't go into the details of how to fulfill these requirements, but I think it is important to have those steps listed in a spec. Again, TODO and others have plenty of material on this.

[shanecoughlan]

Just popping in here to confirm the thread is seen and I will be swinging back very soon. :)

[Jimmy-ahlberg]

I would suggest that we put the topic of scope up for discussion during the next call. I.E if the scope is all outbound open source activities, including incubating and setting up new projects. Or alternatively if the scope is only covering contributions to existing projects.

There are a number of ways to address this, my personal view is that we should focus on contributions to existing projects. The reasons for this is not that I don't think we should cover the "incubation/new projects" but that I think we should do that in a spec of its own, alternatively we can add that to a later iteration of the contribution spec.

In terms of urgency I think that there are a lot more organizations contributing to existing projects than creating new projects, thus it seems more urgent to me to address the contributing to existing projects first. Trying to create a spec that covers all the things that should happen when creating a new project risks to dilute the aspects focused on contributing to existing projects. Finally its also about the ease of adopting the specifications we create, most organizations will likely be contributing to projects before they create their own. So having the spec cover the contribution to exist projects only make sense to ease adoption of the specification, making sure organizations can contribute, using best practices for governance and process, as soon as possible, without having to adopt processes for something that might be far in the future for that organization (creating new projects).