GOV Proposal: Create A Policy For Handling Invitations to Collaborate

[JonathanBechtel]

SKTime has received inquiries recently about collaborations that are commercial in nature, and we want to have a clear policy on how they should be handled in the future.

This is a suggested set of policies on how they ought to be processed, as discussed at the SKTime Community Council Meeting on 08/15/2023.

The primary points are as follows:

• There should be a clear distinction between a charitable donation, and one that has an expectation of services rendered
• For solicitations that involve services being rendered, we primarily separate them into two categories:
  1. Those that need help using SKTime as a tool (ie, companies that need help using sktime on premises, consulting help on a proprietary project)
  2. Those that want to leverage the SKTime brand and occupy some control over how its used (investment opportunities, co-branding, etc)
• In general we're open to the first opportunity, skeptical of the second and prefer to stay away from it.
• For inquiries about using SKTime as a tool, the intention is to have the SKTime organization remain neutral and not accept payments, but individuals who are well suited to handle the incoming requests may decide to volunteer their services
• We'll update the code of conduct so that anyone who's officially affiliated with the SKTime org has to officially disclose the matter before and, and (possibly) get approval before the project begins
• Failure to do so will be considered a code of conduct violation, and is grounds for removal from the SKTime organization.

This is meant to be a template, and not a final say in the matter.

Additional issues to consider are the details of how such issues will be delivered to the SKTime organization, and what the official communication channels will be.

[benHeid]

Thank you for this issue:

Regarding the approval, I think core developers, council members, and other people that are officially affiliated with sktime should require an approval by the community council for collaboration with a third party at least under the following circumstances:

• The third party offers a paid contract to the core developer, ...
• Content of the contract is to implement specific algorithms in sktime or more generally add changes to sktime.

I think in this case transparency is not enough and we should go a step further to avoid any conflicts etc.

Open question

• Should situations where the contract is not about changing sktime but about supporting someone in deploying sktime algorithms etc. also be approved? [Personal opinion: Transparency here would be sufficient]
• How could we administrate this?

[fkiraly]

For reference, adding the summary of our discussion at the Aug 15 council meeting: https://github.com/sktime/community-org/blob/main/community_council/previous_meetings/20230815-meeting.md

[fkiraly]

summary of my opinion below.

Regarding the general policy:

• it is important to have a policy for this, and it is important before there are concrete opportunities on the horizon that pull people into conflicts of interest (this was one of the failure modes of the 2022 council)
• the code of conduct already stipulates a degree of transparency and equal opportunities
• it is also importat we define a scope. We cannot regulate what people do in their private lives or day jobs, but that does not mean the scope must be empty (in fact, this was previously also used as an argument to evade any conflict of interest scrutiny)
  • regarding scope, the equivalent of any standard charity or corporate conflict of interest should do, considering sktime an unincorporated associated (or considering it, only for the purpose of the rule, what if it were incorporated)
  • that basically implies (i) people in execution of their roles, and (ii) anything implying "on behalf of" (the project) rather than "use as a component" (which is fine since permissive license)
  • example out-of-scope: someone giving a course on sktime, and they do not claim, nor are they affiliated with sktime
  • example in-scope: an sktime councillor entering into a consultancy contract that involves contributions to sktime

Regarding what the policy should be:

• my minimum expectation would be "minuted reporting to the community via council as soon as possible". A discussion in public can also go towards this requirement.
• closer to the maximal end, I would actually require council approval for contractual relationships, if they fall in scope (e.g., a councillor receiving funding using the name "sktime" somehow) - this would include academic grants as well as consultancy contracts
• an interesting question is how to deal with priority, scooping, market advantage, etc. This issue could be relevant GOV Proposal: Decisions with delayed announcement date #56 - i.e., minuting a reserved decision and releasing it with a delay.
• conflicts of interest should always be declared publicly in my opinion - as a corollary, primary affiliations of formal role holders should be made public on the sktime members page as well.

[fkiraly]

For comparison, here is Wikipedia's conflict of interest policy:

https://en.wikipedia.org/wiki/Wikipedia:Conflict_of_interest

This is highly relevant as "neutrality" is also part of sktime's mission statement.

[fkiraly]

Here's another interesting question: if we take the wikipedia model at face value, does this tell us something about the relation of algorithm owners and role holders? Let's consider the case of an academic who wants to promote their algorithm.

We cannot directly generalize wikipedia entirely, as such an academic would naturally be the primary maintainer of their algorithm - but maybe they can't be involved about decisions like listing, curation, or have lower priority on docstring decisions (e.g., "the most advaned algorithm to do X!")

Also interesting, the section on "paid editing" in wikipedia.
I think there is less of an interest pressure on sktime since it is currently not primary means to popularize algorithms, so I expect less of this kind of promotion, but still the kind of conflict of interest could appear.

[fkiraly]

Here's my comments on the specific proposal by @JonathanBechtel.

General comment: rules should be actionable, with clear checkable conditions - i.e., it should be easy to verify when conditions are met or not, and what the action is. The further away we are from that, the higher the risk of arbitrary decision making.

This is imo especially important for rules that have penalties as consequences. We do not hope to invoke them, but when we have to, it's important they are "robust" in the above sense, both from a moral/justice and from an applicability standpoint.

here should be a clear distinction between a charitable donation, and one that has an expectation of services rendered

Morally, agree - although how do we make that distinction, process-wise? How can it be checked? Or is this more a general policy line?

As a side note, the current statements on the Open Collective donation tiers do mix the two. These are old - 2020 or 2021 - so we may want to rethink them. As said I agree with your rationale, @JonathanBechtel.

For solicitations that involve services being rendered, we primarily separate them into two categories:

• Those that need help using SKTime as a tool (ie, companies that need help using sktime on premises, consulting help on a proprietary project)
• Those that want to leverage the SKTime brand and occupy some control over how its used (investment opportunities, co-branding, etc)

Hm, agreed - this is perhaps the interesting line, as it separates use of from control of.

Re general comment - how do we distinguish this? The lines can be blurry. E.g., what about co-branding of the kind "we use sktime", or listing a company as a user in our testimonials?

In general we're open to the first opportunity, skeptical of the second and prefer to stay away from it.

Agreed.

I think this is implied by our "neutrality" policy.

The second kind is a slippery slope towards turning into [insert any recent bad example here].

For inquiries about using SKTime as a tool, the intention is to have the SKTime organization remain neutral and not accept payments, but individuals who are well suited to handle the incoming requests may decide to volunteer their services

Hm, I don't entirely agree with this.

• I think we would be missing out on a revenue stream to fund bugfixing and maintenance activities
• this would enrich individuals at the expense of community funds, in a situation where the opportunity is benign
• and/or one could expect (or even require) some amount of "giving back to the community" if the individual in question is a core dev or councillor
• conflict of interest handling must be crystal clear hear imo

but individuals who are well suited to handle the incoming requests may decide to volunteer their services

I think it's important to think about process here to ensure fairness of opportunities, especially about broadcasting the opportunity. E.g., if the request comes via direct message to one person; or, sent to the sktime council email; or, at a job address but clearly with the expectation to represent sktime, etc. If the initial contact is already rerstricted, is it really "volunteering" if it wasn't broadcast to [scope to be defined]?

We'll update the code of conduct so that anyone who's officially affiliated with the SKTime org has to officially disclose the matter before and, and (possibly) get approval before the project begins

Agreed, CoI handling is important. Although the CoC has some provisions on this already (see there).

Failure to do so will be considered a code of conduct violation, and is grounds for removal from the SKTime organization.

See my general comment again - I agree morally, but I feel the conditions on what "this" exactly is are unclear. Examples of what would be considered a violation are important for this, as well as a more precise statement on scope, expected behaviour, etc.

[marrov]

I believe that what would happen most often, which would be that a dev is consulting for a company to use sktime as a tool, should be out of scope for this. I understand everyone agrees with this, but I was not completely certain from reading the above.

Other cases where sktime is contributed to through the express interest of a paying third party should go through approval and benefit the project economically. Nevertheless, I think this will be rare.