-
-
Notifications
You must be signed in to change notification settings - Fork 99
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
Comments
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. |
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. |
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... |
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. |
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. |
Looking up at IETF, they have the following section at https://www.rfc-editor.org/about/independent/:
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? |
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? |
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. |
I want to take the discussion back a bit to whether or not COI disclosure should be mandatory. For example:
So COI disclosure is a good idea but it can create an uncomfortable situation for individual contributors, who might feel that they are now required to disclose their unrelated employer, creating an appearance of association with that employer where none need exist. For this reason I think that COI disclosure should either be optional except for defined cases like Element employees, as previously discussed, or we should permit a more generic COI disclosure of just stating that you are contributing in your personal capacity. A lot of organizations end up with policies along these lines, which basically amount to COI disclosure being required in enumerated cases like:
It's not unusual for this to end up being a disclosure form with checkboxes, one of which is "none of the above." In other words, someone's CoI disclosure will often just be that they have nothing to disclose. |
This sounds sensible and it's actually how I've already understood the disclosure proposal so far. The intention is to call out when there is a conflict of interest, not to make people share unrelated information about themselves. |
it may also be worth considering the IETF process here. The drafts are a different structure, but the principle of putting a company name in the author metadata discloses who "sponsored" the work. The field is optional, allowing individuals to submit drafts too. We could do the same here: simply request the company name be mentioned (eg: Foundation, Element, Beeper, etc) or leave it blank for individual contributions. Team names are completely voluntary, even when listing a company. |
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]:
The text was updated successfully, but these errors were encountered: