openSUSE:Membership lapse summary
Revised proposal
At a time 4 month' prior to a member's even number year anniversary (that would be year 2, 4, 6...) attempts will be made to contact the member via the known e-mail address. Initial contact attempts will be automated to reduce work for the membership committee.
The automated e-mail will contain a link to a web page that enables the member to check areas of contributions to the project. Submission of the form results in automatic membership "renewal" until the next even number anniversary of the member.
Should the automated e-mail bounce 2 more automated attempts will be made to contact the member within 3 weeks of the initial automated e-mail. Should these automated attempts fail a member of the membership committee will make an attempt to locate the member via ML messages, IRC, and possibly other means such as social media. This is a best effort attempt to contact the member.
Should the automated e-mail arrive (not bounce) but the web form should not get submitted, 2 more automated attempts will be made to contact the member within 3 weeks of the initial automated e-mail. Should these automated attempts fail a member of the membership committee will make an attempt to contact the member with a personal e-mail message or locate the member in IRC, Connect or other media. The member will be requested to submit the web form. This is a best effort attempt to contact the member.
In the event that a member cannot be contacted in the 4 month time frame or a member is no longer contributing to the project the member will become an Honorary member.
Honorary members retain their @opensuse e-mail address. However, honorary members may no longer participate in any voting activities that are open only to members.
Resuming contributions to the project at any time will provide an honorary member with the opportunity to request reinstatement as a member to resume vote participation.
Status
The discussion of the revised proposal is on the -project mailing list in this thread.
The discussion did reveal some new questions/concerns that were not previously raised. However, these concerns/issues are already addressed in the current membership guidelines. Therefore a new section was added to the membership guidelines that addresses the discussion of moving non contributing members to emeritus status. This new section is under review by the membership team and once the review is completed will be presented to the board and potentially membership for a vote.
Initial proposal
On even years of membership anniversary (that would be year 2, 4, 6...) a member gets an automated e-mail.
- If the e-mail bounces and there is no other means to contact the person than the person is removed as a member.
- If the person does not respond within two weeks, another e-mail is sent. If after 2 additional weeks no response is received the person is removed as a member.
A response to the received e-mail should include a short list of areas in the project where the member was active during the past two years. This can be verified by the membership team. With the response and verification membership continues.
Current status
- We have no definition what it means to be a member in good standing
- Many clubs or associations charge a yearly membership fee. Members in good standing are defined as those that pay the dues. In our project good standing is not measured by financial means, but by contributions to the project. As contributions are a basic requirement to being accepted as a member.
- Membership does not lapse or is revoked unless an individual
- repeatedly violates the Guiding principles
- actively requests removal
Why is this being considered?
- Accumulating a long list of inactive members is not in the best interest of the project
- This may show in election participation as percentage of membership that casts a vote. While it is perfectly reasonable for active members not to cast their vote on issues concerning the community/project, having a large inactive block of members (that does presumably not vote either) takes away from those active members that due not vote out of protest or other personal reasons. (If you choose not to decide you still have made a choice)
- Having a large block of inactive members promotes the impression that the community does not/can not sustain a functional project.
- We want those that are members to contribute to the project
What is not intended
- In no way should this action or the lapse of membership be misconstrued that past contributions are not valued.
- The openSUSE projects in accordance with our guiding principals is based on mutual respect and the appreciation of contributions. We have no intention of minimizing the value of past contributions. However, the project does evolve and those who are active should be recognized for their current contributions. Membership, if the contributor so desires, is part of this recognition.
High level summary of discssion
There were in general no strong objections toward pruning the list of members to those that are active in the community.
A minor concern raised was about the current rules being interpreted that "free" (as in I no longer contribute) life time membership is possible. This concern was not echoed by a significant number of discussion participants.
One message attacked the idea of making any changes to the current membership rules. Unfortunately the message was written such that any potentially useful discussion contributions were drowned out by all the shouting.
As usual in governance discussions the mail thread received postings that did not add value to the discussion. These postings ranged from "abolish the board and membership, as neither is useful" to "a contributor that fixes packages but does not read e-mail may loose membership because the contributor is too busy contributing". We will always have objections at the extreme ends. However, these outliers should not deflect the attention from the general positive reaction.
Common to many discussion contributions was that prior to any membership lapsing a strong effort must be made to contact the person in question. This can be summed up as "it is better to have some inactive members than to lapse a membership based on inaccurate information".
Conclusion
In general those who participated in the discussion support a process that allows the project to prune the member list to those individuals that contribute to the project.
Implementation details
"Renewal" Time period
There were no objections to the 2 year renewal cycle. One poster proposed a 1 year renewal cycle. However, considering the time period proposed to approach members (more on this below) about "renewal" a 1 year period appears too short.
Approach and response period for renewal
A number of objections were raised concerning the 4 week contact and response period suggested in the original proposal. Generally 4 weeks was considered an insufficient amount of time for this process.
A consensus appeared to emerge around having a 3 to 4 month window. Thus members should get an e-mail (more about contact methodology below) 3 or 4 month prior to membership lapse, i.e. 3 or 4 month prior to their 2 year, 4 year, and so on anniversary.
Contact methodology
Concern was raised about using e-mail as primary contact methodology. E-mails get lost, filtered, blocked, etc. However, arguments persisted that we as the project need a valid e-mail address and thus e-mail still appears to be the best approach.
Contact attempts
Bounced e-mails
Should an e-mail bounce repeatedly manual intervention is required. An effort is required to try and contact the person by other means. This might include a message to the project mailing to explore whether or not another community member knows the person in question. If the IRC nick is known an attempt can be made to find the person in IRC.
Non response
Should the contact e-mail "arrive" and there is no response to to automated message a personal attempt to contact the member whose membership is about to lapse should be made. Presumably we would need volunteers from the community to handle this personal out reach.
Expected response
The expected response to the "membership renewal" mail is either
- an mail that says the person is still interested in being a member and shows verifiable project contributions
or
- clicking a few check boxes on a web page we would set up
- the web page could easily contain check boxes to allow the "renewing" member to indicate the areas of the project where she/he contributes.
During the discussion it was suggested that someone may retain membership just by indicating an interest in the project and voting. However, this appears to be insufficient. Why should the standards of maintaining membership be lower than the standards of attaining membership?
Grace period
As "life happens" a concern was raised that memberships would lapse for people that just happen to have been pulled away from the project for 2 years and have the intention of returning an contributing. Letting membership lapse for this group of people may be discouraging and thus they may not return. Therefore, a grace period of one renewal cycle was suggested.
The counter point to the grace period was that it is difficult to track and that a 4 year inactivity period appeared really long.
No clear solution emerged in the discussion. It appears that while the grace period is a reasonable approach to facilitate the return of former active contributors, it also appears impractical with the infrastructure we have in place today. (more on infrastructure below)
Automation and infrastructure
The member list pruning effort will add additional work to the membership committee. However, with a soft introduction, i.e. don't try to prune the current list at once, and the spread out time period of the even number anniversary years this should not cause an undue burden.
It was pointed out that the whole process of tracking contributions and contacting members should be automated. While the automation resonated well, the lack of tooling makes this approach not feasible at this time. Once the process is in place the community can work on tooling to start tracking wiki contributions, bugs filed, packages maintained, committed, fixed etc. Once tools are available any given members activity can be known and the process can be automated. Even to the point where "your membership will lapse" message are only sent to those members that have not contributed in the given period of time. This needs a lot of work and should not hold up the process of implementing the addition in question.
Acknowledging past contributions
Those whose membership lapses should not be forgotten, this was a common theme amongst a number of contributions to the discussion. Therefore the project should maintain a list of past contributors, similar to today's member list. This will acknowledge the past contributions of those that are no longer actively contributing to the project.
Membership levels
An introduction of membership levels was proposed to indicate which members are currently active, for example tying the levels to releases and giving members that are active during any particular release a member12.1 status for example.
This did not get much traction. Also this would increase the membership work significantly as we'd have to check for every release which members contributed. With not tooling in place this appears to be not practical. Having a black and white status, i.e. member or not appears more straight forward.
A second membership grading level was introduced into the discussion by making the distinction between members and non-voting members. The claim is that such a distinction would be necessary for a foundation. The discussion in this line of thought also touched on "mandatory voting".
A number of people opposed any notion of mandatory voting. On the member and non-voting member distinction there appears to be a divide. On one hand are those that argue that we have to have a certain percentage of members vote to legally valid as a foundation, KDE was used as an example where non-voting members can not "block" forward progress by not participating in votes as only participation of "voting" members is counted toward % of voters. On the other hand the argument is being made that those classified as non-voting are "robbed" of their voice, if they do not vote out of protest.
Public posting of memberships about to lapse
It was suggested in a few messages that names of members that let their membership lapse be posted to the project mailing list. This would give people a chance to "intervene" if there is a pending lapse due to a breakdown in communication.
@opensuse e-mail addresses
No consensus emerged about handling of e-mail addresses for those memberships that lapse. Discussion centered around whether or not those addresses should be disabled and the potential technical implications of such a step.
Communication
Please post any comments to the ongoing "Membership" thread on the project mailing list.
Mailing list
- project@lists.opensuse.org - List to discuss project related topics.
Subscribe - Unsubscribe - Help - Archives