Create expectations for foundation draft#6
Conversation
rubys
left a comment
rubys
left a comment
There was a problem hiding this comment.
I think a lot more work would need to be done before posting something like this as expectations.
For example, looking at: "Project representation on the Board", and comparing this idea with existing bylaws:
- Would these new members of the board be a voting or non-voting member?
- Does naming a member by a project require board approval?
- What about membership in other member committees?
- And the crucial one: how does this impact the requirement that there can be no more than one board member from any parent company?
My experience is that you don't just capture a requirement like this and hand it off to a lawyer. They will inundate you with a thousand questions that will make the four I listed above look like child's play.
Given that this requirement isn't addressed by either existing foundation's bylaws, isn't obviously a new problem created by the proposed merger itself, and is likely to require a lot of work and has an uncertain chance for success, may I suggest an alternative?
Figure out what problem you are trying to solve by proposing board representation, and focus instead on splitting that work out into a committee, and focus on chartering that committee in ways that are acceptable. Adding more to the board isn't sustainable. The TSC is an perfect example from Node.js. You don't want the board to routinely set technical direction? Have that work delegated. Examples of committees that exist at the ASF: Brand Management, Conferences, Data Privacy, Finance, Fundraising, Infrastructure, Legal Affairs, Marketing and Publicity, Security Team, Travel Assistance, and W3C Relations. I'm not suggesting that $FOUNDATION create exactly those committees or a subset thereof: instead find unique problems that needs to be solved at this foundation and lets structure committees around solving those problems.
|
I'd also recommend reading section 4.5 from either bylaws concerning the circumstances by which the board can remove a member. |
|
From today's meeting Sections of bylaws that merit a lot of attention include:
|
| - Annual reviews of staff, NPS, board, programs, support services to projects for accountability and incremental improvement | ||
| - The foundation staff, executive director, and board should follow a "servant leadership" style. | ||
| - Project representation on the Board | ||
| - Projects could have tiers, only 'platinum' projecs should sit on the Board directly. Other projects would have shared seats(like gold/silver member strcuture) |
There was a problem hiding this comment.
Projects could have tiers, only 'platinum' projects should sit on the Board directly. Other projects would have shared seats(like gold/silver member structure)
There was a problem hiding this comment.
I think we are better off keeping this framed as community representation rather than project. But we do need to reach consensus on this
MylesBorins
left a comment
MylesBorins
left a comment
There was a problem hiding this comment.
made some notes inline, I think we want this to be very scope to the things we know today
| - The foundation staff, executive director, and board should follow a "servant leadership" style. | ||
| - Project representation on the Board | ||
| - Projects could have tiers, only 'platinum' projecs should sit on the Board directly. Other projects would have shared seats(like gold/silver member strcuture) | ||
| - Community representation on the Board: 1 seat guaranteed for the Cross-Project Community Council and 1 seat for Individual Membership program if and only if threshold requirements have been met(TODO) |
There was a problem hiding this comment.
I'd prefer this to state, minimum expectation keeping 3 current community seat
|
|
||
| - Communicated scope for the foundation and board | ||
| - Annual reviews of staff, NPS, board, programs, support services to projects for accountability and incremental improvement | ||
| - The foundation staff, executive director, and board should follow a "servant leadership" style. |
There was a problem hiding this comment.
"servant leadership"
is there a better way to phrase this?
| - Annual reviews of staff, NPS, board, programs, support services to projects for accountability and incremental improvement | ||
| - The foundation staff, executive director, and board should follow a "servant leadership" style. | ||
| - Project representation on the Board | ||
| - Projects could have tiers, only 'platinum' projecs should sit on the Board directly. Other projects would have shared seats(like gold/silver member strcuture) |
There was a problem hiding this comment.
I think we are better off keeping this framed as community representation rather than project. But we do need to reach consensus on this
| - Project representation on the Board | ||
| - Projects could have tiers, only 'platinum' projecs should sit on the Board directly. Other projects would have shared seats(like gold/silver member strcuture) | ||
| - Community representation on the Board: 1 seat guaranteed for the Cross-Project Community Council and 1 seat for Individual Membership program if and only if threshold requirements have been met(TODO) | ||
| - Each council(CPC and Community Council) should have a given allocation of Board seats. How these are allocated should be defined by each respective council. |
There was a problem hiding this comment.
seems premature if we don't yet know that governance structure.
There was a problem hiding this comment.
Happy to remove this detail
| - Projects values should drive foundation focus and priority | ||
| - No "pay to play" in technical participation | ||
| - Earmarking allowed with flexibility in budgeting for concerns and needs of individual projects | ||
| - Value satisfaction: regular feedback from projects |
There was a problem hiding this comment.
we should also include
- ability for budgetary decisions to be delegated
- ability for projects to leave the foundation
| - Each council(CPC and Community Council) should have a given allocation of Board seats. How these are allocated should be defined by each respective council. | ||
| - Board must establish Cross Project Council focused on the specific needs of the member projects | ||
| - Allow projects to self-organize amongst themselves. Processes are defined and driven by project e.g. CPC is not structured by the Board | ||
| - CPC should be co-chaired by the Executive Director of the foundation |
There was a problem hiding this comment.
This seems pre mature given that we haven't locked down governance yet.
we should likely drop this for now
There was a problem hiding this comment.
Yup, a specific detail that hasn't been talked through enough. Removing.
| - Projects could have tiers, only 'platinum' projecs should sit on the Board directly. Other projects would have shared seats(like gold/silver member strcuture) | ||
| - Community representation on the Board: 1 seat guaranteed for the Cross-Project Community Council and 1 seat for Individual Membership program if and only if threshold requirements have been met(TODO) | ||
| - Each council(CPC and Community Council) should have a given allocation of Board seats. How these are allocated should be defined by each respective council. | ||
| - Board must establish Cross Project Council focused on the specific needs of the member projects |
There was a problem hiding this comment.
Is it premature to talk about governance structure in this doc?
There was a problem hiding this comment.
I'm happy to change the name to something more ambiguous, but I think we've heard a fair amount of consistent feedback that something like this is very much wanted. The specific details and governance just haven't been laid out.
| - Projects values should drive foundation focus and priority | ||
| - No "pay to play" in technical participation | ||
| - Earmarking allowed with flexibility in budgeting for concerns and needs of individual projects | ||
| - Value satisfaction: regular feedback from projects |
There was a problem hiding this comment.
Add:
- Foundation should enable trademark usage via supporting community decisions around individual trademarks.
There was a problem hiding this comment.
perhaps more that there should be a clear process to utilizing trademark?
There was a problem hiding this comment.
Updated! See Line 20
|
Since there has not yet been an update to this PR should we remove it from tomorrow's agenda? |
|
We will likely want to update this file with content from here: https://github.com/nodejs/bootstrap/pull/7/files#diff-ad1ebdc23d253b21a8c6f6669edc6083 @hackygolucky, would you like me to PR it in to your fork, or open a new PR with both PR's content? |
|
here are the bits referred to by @amiller-gh |
Remove any details that haven't been discussed enough to be included in this short list
@amiller-gh PR it to this fork if that's okay! Worst case I can add it in but I'd prefer you are acknowledged for the commit(s) |
|
@rubys Thanks for all the work with #8 I think it goes a long way to inform what should be here, especially because the ByLaws are arguably the only area that needs to be signed off on before we figure out concretely whether the merger moves forward–it's the area that projects+boards+exec should be in complete overlapping agreement on in the venn diagram of responsibilities of making the foundation tick. Governance otherwise lies in the hands of the project(s). @MylesBorins @rubys Looking through previous meeting notes and recent issues, have their been any major decisions in meetings that we think MUST be in this doc i.e. dealbreaker level of items to be in the ByLaws that should be here? Anything to highlight in the existing ByLaws of both foundations that we could request to be punted explicitly to the projects' responsibility instead? @jasnell is there anything that was highlighted in the survey re: the merger that is an excellent concern to be surfaced as an expectation? I think the requests around accountability help cover a lot but I don't want to overlook something. |
| - Earmarking allowed with flexibility in budgeting for concerns and needs of individual projects | ||
| - Value satisfaction: regular feedback from projects | ||
| - Explicit acknowledgement and documention for the ability of projects to leave the foundation | ||
| - Foundation should document a clear process for trademark usage to enable community not-for-profit efforts |
There was a problem hiding this comment.
I think this could be expanded. Node.js TSC and CommComm cannot use the trademark directly. It’s not only not-for-profit efforts, but even project representation.
There was a problem hiding this comment.
Has this been a problem in the past? I wasn't aware, if so, which I'd love to hear the details of if there's a case of it.
If folks aren't changing the trademark and are using it -for- the Node.js project, we should already be able to use it. Thus why it's good to have documentation around it. Modification is not okay without permission, and you can't make money off of it.
There was a problem hiding this comment.
I consider a problem that the TSC or CommComm cannot publish a message on social media as nodejs, as an example.
If somebody has access, this is clearly not documented anywhere.
There was a problem hiding this comment.
That is a good point, we can ask Zibby, but you need to know that you can ask her.
There was a problem hiding this comment.
FWIW on the JSF side the projects manage and run their own social channels, and would expect to continue doing so. Is the intent that the board and say a "brand/marketing committee" will be responsible for the new @$Foundation's social account and Node.js (and other projects) are responsible for their own accounts? so the expectation is that the node foundation would turn over the use of @nodejs to the project?
|
Per requests in the last Bootstrap meeting, drafted this thing up HERE after incorporating past expectations documents along with discussions we've been having in this PR. Unless there are any objections, I will close this PR in order to follow the proposal process we have now shipped. |
|
Closing as discussed in the meeting |
10 participants
With the intent to merge the Node.js Foundation and JS Foundation being announced, those interested in the continued support of Node.js and JS-related projects are working through expectations and structure for what the potential new foundation could look like.
This document is for the initial phase of work for the Bootstrap team to draft requirements that overlap with scope of the Board in order to provide an outline and structure for the foundation attuned to the needs of the projects and ecosystem stakeholders who have participated.
If lines are removed from this document, it may not be because they have been -1ed for application in the design of the new foundation but may in fact just be outside of the scope of this particular document.
This document is intended to be delivered to the Node.js Foundation and JSF Boards in order to outline the recommended structure of the foundation and to inform the Bylaws first draft.