Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we require disclosure of potential Conflict of Interest on MSCs? #1700

Open
ara4n opened this issue Dec 26, 2023 · 8 comments
Open

Should we require disclosure of potential Conflict of Interest on MSCs? #1700

ara4n opened this issue Dec 26, 2023 · 8 comments
Labels
improvement An idea/future MSC for the spec

Comments

@ara4n
Copy link
Member

ara4n commented Dec 26, 2023

Suggestion

A recurring theme is confusion/concern from the community over the motives of MSCs, and which ones gets prioritised - especially for MSCs from folks on the Matrix Core Team who are employed to work on Matrix by Element. For that matter, it's also useful for the SCT and community to have more context on a given MSC (e.g. is this driven by Gematik's TI-Messenger work? is this MTRNord proposing something as an independent contributor, or for a Nordeck project?) etc.

So, shall we put a "Disclosures" section at the bottom of the MSC template and ask folks to self-identify the hats they're wearing when proposing an MSC? For instance, for me, it would be something like:

Disclosures

Disclosure: the author is a Guardian of Matrix, a member of the SCT, is Project Lead of Matrix, and employed by Element. However, this MSC is [one of]:

  • Written as an individual FOSS contributor
  • Written as a Matrix spec core team member (funded to work on core Matrix work by Element)
  • Written as a Matrix core team member (funded to work on core Matrix work by Element)
  • Written as an Element employee (funded by commercial Element work)
  • Written as an Element employee (funded by the Ruritanian Government) (if the end customer is willing to be disclosed)
@ara4n ara4n added the improvement An idea/future MSC for the spec label Dec 26, 2023
@tcpipuk
Copy link

tcpipuk commented Dec 26, 2023

I'm all for this as an option, but not as a mandatory disclosure. People are welcome to transparency, but some of us are developing personally and do not want to disclose other "potential" interests that have nothing to do with our interactions here.

@turt2live
Copy link
Member

I do agree that the hat someone is wearing while writing the MSC should be disclosed, though I don't think it needs to be a formal, normative, section of the MSC.

The sign-off email address alone is usually pretty telling where an MSC came from - maybe we should elevate its presence. Likely putting a few words into the description is fine. Conflicts are pretty irrelevant after the MSC is merged, so no need to take up reading time. I have similar thoughts about the Dependencies section already in the template, fwiw.

I strongly disagree with the notion that being employed by a Matrix vendor (ie: Element) means you're required to disclose that employment in the MSC, however. If the MSC is written in such a capacity then it should absolutely be disclosed (and the employer should feel compelled to make the disclosure a thing).

ftr, I do think it should be mandatory for SCT members to both list their employer (if a Matrix vendor or using Matrix) and which hat they've used to write the MSC (if different). This only seems fair, given the position SCT members fill.

Somewhat separately, I wonder if this is still fixing a symptom of a problem. This largely spun out of lack of transparency on why any given MSC sees attention from the SCT at all, and disclosing a conflict of interest doesn't really help solve that. It would provide useful information to know why an MSC was written, but it doesn't speak to the prioritization component.

For prioritization transparency, I think we as a SCT just need to do a better job disclosing our sources of prioritization. This is possibly done with more structured blog posts on the matter, likely centered around the release schedule. We already kinda do that with "upcoming in vNext", but we generally fail to actually mention where those items came from. This will be particularly more relevant once the Governing Board is seated and feeding a level of prioritization into the SCT for consideration.

@ara4n
Copy link
Member Author

ara4n commented Dec 26, 2023

While I think we need better prioritization transparency, an optional disclosure of CoI would still useful if only to give more transparent data on Element-funded work. At least, I quite like the idea of going through historical ones from Element employees and figuring out what hats people were wearing, especially if it can shut down conspiracy theories...

@turt2live
Copy link
Member

Yea, Element specifically may want to make this mandatory and backfill history there. I don't think it should be a requirement in the spec process to do this, though. Optional disclosures sounds perfect and not something which needs formal templating - it could be done today.

@MTRNord
Copy link
Contributor

MTRNord commented Dec 26, 2023

(e.g. is this driven by Gematik's TI-Messenger work? is this MTRNord proposing something as an independent contributor, or for a Nordeck project?)

Those to me are the simpler cases. A) I am not going to touch gematik TIM outside of work due to its quality (sorry) B) I would sign work stuff with my work email. That makes it hopefully clear, as it says nordeck on it. And it says nordgedanken on my private email. (To be fair one could think nordgedanken is also some kind of group or company but turned out mtrnord is a domain I don't own).

Imho its actually hard to come up with a good case apart from those involved in the core team as coders (like SCT members which work at element or js-sdk devs). I tried to come up in a scenario where having a work email is unlikely and maybe then its unclear. Like a company using private emails for whatever reason.

I guess one result of that could be that it should be marked in one clear way. If thats email or a COI declaration in the end makes no difference imho. If its already clear by the implementation location, email or similar then I dont see a reason for declaring the (possible) COI. If its totally unclear (generic email hoster, no implementation and alike) then it would be nice to have it.

@KitsuneRal
Copy link
Member

Looking up at IETF, they have the following section at https://www.rfc-editor.org/about/independent/:

From time to time, the Independent Submissions Editor may have a conflict of interest, or the appearance of a conflict of interest, with regard to a particular draft. This can occur for a number of reasons, including when submissions are received from people who are employed by the ISE’s employer or its competitors. Such relationships in and of themselves may not lead to variance in the editorial process, but they must be disclosed.

When the ISE believes that there may be a conflict of interest, or if authors or others believe that there is a conflict of interest, the matter will be referred to the Independent Submissions Editorial Board. They will advise the ISE as to what should happen at the various stages of the publication process. The ISE will inform the community and authors of such conflicts, and any actions to be taken as a result.

Looks reasonable to me. Notably though, this is not about "hats" but rather the actual standing wrt to entities that can influence the decisions of SCT. Which, for now, is Element only?

@turt2live
Copy link
Member

We've been trying this out on a few MSCs this year, many of which are linked to this issue - how do folks feel about the content? Is it helpful?

@turt2live
Copy link
Member

I'm taking the lack of written feedback to mean our usage is perfect and no changes are required.

Next steps are to formalize this in the spec proposal process, and require it from contributors beyond the SCT.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement An idea/future MSC for the spec
Projects
None yet
Development

No branches or pull requests

5 participants