Candidacy disqualification for persons that work for a node sponsor

[scriptjs]

I believe there needs to be a rule to disqualify any candidate for a seat on the board if you work for a company that sponsors node. This could serve to stack the board. Developers need to be assured of unbiased representation and advocacy. While board members do not make decisions as part of the TSC, they influence policy and legal decisions with an impact upon the project.

[Danese]

Howdy,

I totally get why you raise this issue, but the problem with limiting Board membership by employer is that people change employers.

On some of the Boards I work with we do impose a limit for optics reasons (typically of no more than 2 people working for the same company serving concurrently), but it can quickly get crazy when you lose great Board members mid-term because they've changed jobs (or their company has been acquired).

FWIW, Apache records who is working for whom (for all Members and Committers), but they impose no restrictions on Board composition (because Board Members are supposed to check their corporate affiliations at the door and act as individuals).

Of course the Node.js Foundation is largely made up of people sponsored into their board seats by employers, but the majority of us also have long experience serving on open source Boards and hence call out our conflicts and biases.

When I served on the OSI Board I recused myself from votes in which I had a conflict of interest (such as whether a license my company wrote was "OSD Compliant".

Hope this helps, D

[mikeal]

@scriptjs the positions are "at-large" meaning that the employer is not a factor. The members who elect the candidates are electing them on their own merit, not their employers, and as such their term on the board is not effected by their employment status. This is pretty standard across industry boards for "at-large" candidates.

[jasnell]

@scriptjs please keep in mind that the intent of the individual member election for the community of individual members to elect an individual to represent their interests as opposed to any single corporate entity. The membership will select the individual candidate that they feel best represents those interests and the person selected will be accountable to and expected to fill that role. The individuals who put themselves forward as candidates are making a good faith public commitment to fulfilling that role. It is up to the individual members to determine whether or not they trust that individual enough to represent them.

There are two key challenges: with disqualifying any individual person from running for this election on the basis of their employer: (a) we potentially restrict the community from selecting the individual the community feels best represents their interests and (b) given that any employer can become a sponsor of the Node.js Foundation at any time we can end up in a situation were all candidates that may potentially put themselves forward do not feel safe to do so.

[mikeal]

There are two key challenges: with disqualifying any individual person from running for this election on the basis of their employer: (a) we potentially restrict the community from selecting the individual the community feels best represents their interests and (b) given that any employer can become a sponsor of the Node.js Foundation at any time we can end up in a situation were all candidates that may potentially put themselves forward do not feel safe to do so.

(c) Once elected employment can change and someone elected while not working for a member could later be employed by one.

[scriptjs]

@jasnell @mikeal @Danese I appreciate this feedback. Given this remains an election despite being nominated, we have to put faith in those casting votes. I would like to believe in advocacy that above the influence of an employer but I am not sure that can exist in real terms despite a strong desire to serve a community. Though I agree with much of what has been said, @jasnell is correct in that trust has to be placed on the election as to who should earn the position on merit and advocacy.

[jasnell]

@scriptjs ... just so it's clear, part of the concern here is not about specific points you are raising. You have a point of view, you have a reason for having that point of view, and you have every right to share it and expect it to be addressed. You obviously feel passionately about this community and that is a fantastic thing. We need passion and commitment from as diverse a community as possible. The concern, however, is that by aggressively posting your concerns across multiple threads of conversation, repeating the same arguments in multiple forums with the same audience, the concerns can begin to start being interpreted as harassment by the individuals to whom those comments are being directed. I do not believe that is your intent, but it is something to keep in mind.

With regards to npm, I see three distinct issues being raised: (1) npm involvement with the board, (2) our bundling of the npm client with node core and (2) the technical design and implementation of npm. The appropriate forum to address issues 1 and 2 are (as I've mentioned before) the nodejs/TSC repository. The TSC can be asked to review the issue and raise any concerns that need to be addressed by the Board. You can also voice your concerns to @mikeal, @Danese or any of the other Board members and I'm sure those will be given a fair review.

To address the third issue, the right places to discuss the future technical direction of npm are either the nodejs/NG repository (as is already being done) or the npm/npm repository. I know you feel that directing the conversation to npm/npm has been ineffective so I encourage you to engage the nodejs/NG repository further. I am quite happy to see constructive technical conversation going on and will say that the absolute best way of influencing the direction here is through concrete technical contributions.

[scriptjs]

@jasnell Good points. I will take this into consideration with my posts.

[mikeal]

@scriptjs you may want to consider editing or moderating some of your prior comments in candidate threads.

[scriptjs]

@jasnell arghhh. The decentralized module delivery issue is closed in node/TSC. I'd say this. I can write up a formal proposal if this what we need to move forward. I like what we were talking about yesterday but the discussion seems to have gone south where it was being held. I am getting weary with all the talk frankly. I want change. If we cannot work to create it node, I will simply compile the changes into a custom binary and forget about attempting to change the status quo. It seems quite uphill.

I don't know if there is any specific format to follow for a formal proposal. Please point me to something if if that is what we need to have this move forward. I can come back to demonstrate a possible solution where it can be used as the basis of some further discussion, or not.

[jasnell]

@scriptjs ... a formal proposal with concrete technical details is the appropriate way forward. One process that we have been working to get off the ground are the "Node.js Enhancement Proposals" (https://github.com/nodejs/node-eps). From the readme in that repository, "The idea behind the EP process is to keep track of what ideas will be worked on and which ones where discarded, and why. This should help everyone (those closely involved with the project and newcomers) have a clear picture of where Node stands and where it want to be in the future." The readme also contains a clear description of what is expected in the proposal to frame the discussion. New proposals are submitted as Pull Requests. The discussion is expected to remain focused on the technical issues of the proposal, which means any commentary on other matters not related to the technical detail of the proposal (such as the npm organization) are out of scope for those discussions (and would possibly be deleted from the discussion thread).

The nodejs/NG forum is intended to be a forum for discussing future technical directions of the Node.js platform but the discussion thread that was opened there just kept going off the rails rather than focusing on the specific technical concerns of package management in Node.js. I encourage you, and anyone else, to work on concrete technical ideas to bring to the community. It's impossible to say whether or not we'll adopt any single idea or not but we should be having those discussions. We just need to make sure that the discussions stay productive, stay on topic, and demonstrate a respect and consideration for every participant.