search

nodejs / board

The Node Foundation Board of Directors
52 stars 28 forks source link

Draft Policy for Board Approval #11

Closed mikeal closed 8 years ago

mikeal commented 9 years ago

We need to get the individual membership terms ready for board approval.

Membership Cost

Did I miss anything?

rvagg commented 9 years ago

do TSC members get to vote?

Morgul commented 9 years ago

@mikeal There seemed to be some support for the Apache version of STV over on #8, as opposed to majority wins. I'd like to push for that, if possible. Other than that, though, it all looks good.

mikeal commented 9 years ago

@rvagg TSC members can vote if they are members, they just cannot run for the member seat because they are already represented by the TSC Chair.

I expect the number of individual members to be quite large and the TSC seats quite small, but the TSC seats do shuffle around a bit over time and it would be quite annoying to try and keep track of which members are excluded from voting because they have a seat.

@Morgul I like STV but dread building that tool as it will be difficult to use the same tool Apache does because we need GitHub integration and the Apache tool is a gigantic ball of Java :(

Morgul commented 9 years ago

@mikeal If it's just a question of writing a tool with github integration, I'm sure we can get that done. If nothing else, I'll volunteer to write it if that's the only way to get STV done.

mikeal commented 9 years ago

@Morgul I just don't want this to get derailed bike-shedding a tool. I'd rather stick with a simpler voting mechanism to start and then once we have a working PR to add STV voting we can move to that.

mkdolan commented 9 years ago

We often find Condorcet voting works well for these elections. CIVS is an example online tool for this. It's not visually sophisticated but does get the job done. http://civs.cs.cornell.edu/

mikeal commented 9 years ago

This looks like a great tool, and only requires that we have a list of email addresses.

Morgul commented 9 years ago

@mikeal, @mkdolan I'm ok with CIVS.

Burstaholic commented 9 years ago

Just to note, I had much the same thought as morgul (simple majority/plurality just doesn't perform very well). CIVS seems like a very good system.

jasnell commented 9 years ago

LGTM. CIVS is a good place to start.

guyellis commented 9 years ago

For the open issues...

Time-line for first election I'm throwing out 1st October for no other reason than it's around 3 months for now. Correct me if I'm wrong but time-line for first election is a series of dates:

For signup and money collection what is the MVP?

mikeal commented 9 years ago

I'm throwing out 1st October

I'd say that we should set a goal of "Elections will begin 2 months after individual membership signup is available." That way the election pushes out if we drag a little bit on having the signup ready.

mikeal commented 9 years ago

https://nodejs.org/foundation/member-signup ?

Probably easier to have the app at a subdomain like http://membership.nodejs.org .

guyellis commented 9 years ago

Good point @mikeal on the 2-months-after. That kind of settles the timeline for the first election and moves the target date to getting membership setup if nobody else has a better idea.

@mkdolan Do you have an opinion on collecting money? What would you recommend for the first iteration of membership?

Assuming that we need some app/DB combo for membership or we need to use a SaaS what are the available options that already exist that others ready this have used? A quick search of Npmjs threw up https://www.npmjs.com/package/node-stripe-membership-saas - I have no experience with this or any other membership apps so have no opinion. What have others used?

mikeal commented 9 years ago

@guyellis it's pretty trivial to drop a Stripe checkout widget on a website and the money comes much faster than Paypal.

guyellis commented 9 years ago

Does Stripe support subscription and/or do we need subscription?

guyellis commented 9 years ago

Apologies - that was lazy of me - I should have looked it up first - yes they do. https://stripe.com/docs/subscriptions

guyellis commented 9 years ago

If nobody has a better suggestion than https://www.npmjs.com/package/node-stripe-membership-saas for a membership app then I recommend that we fork it into the nodejs account and create issues against it to customize it for Nodejs Foundation Membership. Objections?

Morgul commented 9 years ago

I'm fine with that.

mikeal commented 9 years ago

@guyellis I have half of this app already written (the GitHub login and org/team checking) because I'm putting together a proof of concept for a twilio backed conferencing system since we've had so many problems finding a good one. But it's not using express so it will be hard to integrate if we go down this framework path.

guyellis commented 9 years ago

@mikeal Let's go with what you have. I was throwing that out as an option to try and get this moving. Do you have a repo and list of issues against it to get us to MVP for this?

mikeal commented 9 years ago

@guyellis I'll work on getting what I have up somewhere today. Right now all my API keys are just embedded in the source so it'll take a minute :)

mikeal commented 9 years ago

@guyellis https://github.com/mikeal/openconf all it does right now is login to github and list the orgs you are in. there is also zero design :)

mikeal commented 9 years ago

Quick Update:

The Linux Foundation has a system they've been using to manage individual membership. It's currently a bit LF specific but they are looking to broaden it for use by other organizations. After a call with them about our requirements they are considering the following:

I walked them through the requirements we've been discussing here and they all seem pretty doable. The last remaining thing is adding new members to a foundation github org & members team. They may be able to do that with an API request or we may just periodically do an export and sync it with that team.

The nice thing about this is that the payment/renewal system will be directly integrated in to the voting system. This is important because we must ensure that only members vote and when you work in the renewal process and the possibility of contesting charges it's very hard to keep the financial standing of a member perfectly in sync with the GitHub team.

Additionally, legal concerns have been raised about condorcet voting related to Delaware corporate law (which is important because our 501(c)6 is registered in Delaware). IANAL but it would be expedient if we could table the use of that voting system. The OSI recently used Helios (an open source voting system) for their elections and it sounds like it would be pretty easy to integrate with the LF's identity system. The LF team is going to investigate Helios integration/hosting. One important part of Helios which we haven't properly addressed yet is the privacy of the voting records.

I'll try to keep this thread up to date with where the LF's identity team is at but this could save us a lot of work and help us get up and running with membership elections faster than if we tried to create a system ourselves.

Morgul commented 9 years ago

@mikeal Great, thanks for the update. This all sounds very reasonable, and like the best path moving forward, so I'm very much in favor of it, all things considered.

Regarding the condorcet voting, if there's a legal question, it's more than fair to table it for now, and revist it once we have some additional bandwidth.

rvagg commented 9 years ago

I've been thinking about some requirements we have for voting and would love to spin up a mechanism that could be used by any WG internally or across WGs. I was pondering throwing something together that just tied in to GitHub teams because that wouldn't be hard and it doesn't need to be fancy because I don't think the votes are going to be very important on the most part but perhaps there's a better way to approach this with the LF/NF membership stuff?

Examples include:

mikeal commented 9 years ago

@rvagg This sounds like a great tool but I think some of the priorities are opposing for what we need out of the membership voting system. For instance, anonymity is not a priority for these elections and in fact you may want to discourage or not allow it being that some of the votes lead in to or are decedent from technical debates. Also, it sounds like the most important thing you need for this to work is to have good GitHub integration since so much of this should be open to specific teams -- wheras the membership voting system's main integration point has to be the standing of members, which has a potential financial integration point.

I'd love to work on a new GitHub lightweight voting system with you for the things you've brought up :) It's something I've actually though about before and am very interested in.