16/05/2023 Model Proposal - Section 1, Membership

Community Governance
, ,
1

See parent thread with all sections of the proposed governance model here.

See original text with explanatory comments here.

1. Membership

Anyone who participates in Mautic is considered a Basic Member. They do not have voting rights.

1.1 - Basic member

To join the Mautic community, a person signs up for one of the community channels which include Slack, Forums, GitHub, Jira, Transifex and the Knowledgebase. Joining the community is open to anybody, and they automatically become a basic member.

Basic members do not have voting rights. They can attend and contribute to discussions and decision making processes, but may not vote and are not counted for the purposes of quorum at meetings of the members.

Unless such member affirmatively declines such right in writing, any existing member of the Mautic Community shall automatically become a Basic Member without any further action on the part of such member.

1.2 Voting member

To gain voting rights, there are two ways, financially or practically contributing to Mautic.

1.2.1 Financial contributors

Financially support the Mautic project as an individual, at a minimum rate determined by the Community Council each year in the annual General Assembly (adjusted based on the member’s home location using the Big Mac Index) is the first route to having voting rights.

The base rate for someone living in the United States is $100 per year.

Membership must be paid annually in one single payment.

Individuals may decide to donate more, but this is the minimum amount required.

Upon paying the required minimum amount, such person will be deemed to be a Voting Member for the twelve month period following such payment.

1.2.2 - Practical contributors

You can become a voting member by supporting the Mautic project through making contributions to official Mautic resources which support the project’s growth.

You qualify as a member through practical contributions if you dedicate at least five hours per month working to support Mautic or the Mautic community - for example by organizing Mautic events, working on Mautic projects, participating in one of the Mautic working groups, etc.

You also qualify through practical contributions if you dedicate at least five hours per month working on projects which advance the mission of Mautic by creating or maintaining open source software or resources which are available to the public at no charge.

Members who wish to claim voting rights through this method are required to self-certify via a form each year.

The name, affiliation, Working Group and Project associations of voting Members will be published to the Mautic membership once a suitable mechanism for doing so has been determined.

The Mautic Community Council reserves the right to reject a new application or revoke an existing membership should it be determined that the self-certification was made in bad faith.

1.4 - Fellows

Some individuals have made substantial contributions to Mautic and may be granted a lifetime membership, known as becoming a Fellow.

To be eligible for membership as a Fellow, a member must be nominated by any Member of Mautic other than a Basic Member, or by a specially created Working Group, which nomination should be based upon certain criteria to be established and adopted by the Community Council and which criteria shall be designed to emphasize extraordinary contributions.

Following such nomination, approval of two- thirds (2/3) of the members entitled to vote, or two-thirds (2/3) of the members of the chartered Working Group, or two-thirds (2/3) of the Community Council, shall be required in order for a member to become a Fellow.

Upon election, a Fellow shall remain a Fellow for the remainder of such person’s natural life, subject to any limiting provisions of this document and to not have to contribute financially or practically to retain their status. Fellows may exercise voting rights at any time, and if they vote, shall be counted for purposes of a quorum.

1.5 - Voting rights

All categories of membership other than Basic Membership have voting rights.

1.6 - Changing membership status

Members may convert their membership to Basic Membership or withdraw any tier of membership including Fellow status at any point by completing the membership change request form.

The membership of a member shall automatically be converted to Basic Member status upon the occurrence of any event causing such member to no longer qualify as a member of any membership class other than as a Basic Member.

A member’s membership may be terminated by the Community Council (for example as a result of a Code of Conduct investigation recommendation) with an affirmative vote with two-thirds (2/3) of the members who are present and eligible to vote at the meeting. This also applies to Fellows.

Upon any withdrawal from or termination of the membership of any member, the membership, including all related voting rights, of such member shall be terminated. After a withdrawal or termination of the membership of any member, such former member may reapply for membership in accordance with the application process detailed above, and after following any reconciliation process that might be deemed appropriate after a termination due to a Code of Conduct breach.

EDIT LOG:

16/06/2023: Updating membership types to have just ‘voting members’ and ways to get voting status.
21/06/2023: Add clarification on termination of Fellow status and clarifying that the base rate is set in the annual General Assembly
23/06/2023: Remove responsibility to vote at least once a year, and related reference to having an option to not vote in that year (as it would not be relevant without the responsibility clause any more)

1 Like
2

In general, I cannot agree with the concept of having “classes”.
Based on the discussions and comments we have on the wg-governance slack channel several of us think we should aim to be meritocratic and egalitarian, this section basically walks over all that had been said there…

And this “Fellows” class specifically makes me hurt! it’s like having royalty, cmon…

3

Hello @rcheesley,

Supporting members" are defined precisely in $, “$100 per year”.
Contributing members" are otherwise defined as “dedicate at least five hours per month working to support Mautic or the Mautic community”.

Isn’t it possible to have the same calculation for both? At the moment this is confusing.

What happens to “Featured Partners” and “GitHub Sponsors or Open Collective”?

Pierre

4

I don’t see this in the same way as you.

I see that there are some people who have made immense contributions to Mautic in the past. Without their involvement, our project, product and community would not exist, or at least, it would not be where it is today. They also often have a huge fountain of knowledge which could be very beneficial to the project when we are making decisions, for example.

Some of these people are no longer actively involved in the project and community because lives go on and they are focused on other things now, and we have absolutely no way of recognising that contribution that they have made in the past, or of giving them a way to be involved in discussions or big decisions.

The idea of having a way to recognise those people, and allow them - if they so desired - to have voting rights in the project going forward, is in my opinion a small token of thanks for what they have given us as a project in the past.

This would be a very small group of people, and per the description they would have to meet certain criteria established by the community.

I feel that it is a way to enable folks who have been pivotal to Mautic’s success a way to stay involved in the project, if they so desire, without the need to be actively contributing any more.

Maybe if it’s the wording that is triggering of royalty or exclusivity/class, we could come up with something that is more appropriate (I took this directly from the Python Software Foundation).

On a scale of 1-10 as to how important this is to me, it would be about a 3. I think it’s a nice to have - for the reasons above - but I would be willing to concede it if there are strong feelings against it.

5

Actually this is not the case, because it’s on a sliding scale according to where you are located in the world, to make it financially fair.

I feel that to be considered eligible for membership on a contribution basis, we must have a minimum ‘bar’ by which we consider this path to membership. 5 hours a month equates to just over 1 hour a week. Honestly, I feel this is quite a low bar. Most folks contributing give far in excess of this amount.

I’m not sure I understand you, how do you mean ‘have the same calculation for both’? One is about being eligible to become a member contributing financially, the other is about being eligible to become a member by giving your time, rather than money. This is so that there are different ways to become a member. If you can’t afford it financially, you can give your time. If you’re already giving your time, you don’t have to contribute financially if you don’t want to, because you’d be eligible through your contribution history.

GitHub Sponsors and Open Collective are the financial tools through which people contribute. If you want to become a member through financial channels, I expect that you will still do that through those channels (we prefer Open Collective as there are less fees for the contributor and for us). We haven’t yet got to the finer detail of how the contributions will be made but I expect that it will be through Open Collective.

Community Partners will still continue to exist. These are companies who are sponsoring and also practically contributing. For the purposes of the Governance Model, we are talking about individuals.

So the memberships are all talking about a single person contributing annually that amount, or practically contributing their time. The voting rights are then for that person.

Hopefully that makes things clear!

6

Several members, including our last Head of Product, but also other voices, have expressed their reluctance to use an economic value to accept or refuse, or buy, membership.
Personally I am not against it, but I am very surprised to find it on your proposal without more debate and consultation.

7

If you are referring to conversations in the working group in this thread on Slack, we discussed the behaviours that we wanted to model (to encourage people contributing in a practical sense, and also to encourage people to financially support the project). I agree with that wholeheartedly, I think that we should recognise the importance of both these important ways of supporting the project.

We did also talk about longevity - that you had to be part of the community for a certain time period before you could vote, which I haven’t included above.

My concerns about having only financial or only contribution based membership is that it excludes people for whom that is not an option. If I can’t financially afford to pay whatever the amount is, but I can contribute and do contribute, why should I not be eligible?

Likewise, if (maybe for economic reasons) I am not able to contribute, but I am personally willing to give my money so that I can support Mautic, and I want to have a say in the future of Mautic, why should I not be eligible to vote?

I’m somewhere around a 5 out of 10 on having these separate types of membership for these reasons. I’d be willing to discuss what might be a different approach, but I do think it’s important that we both keep in mind what Mautic needs (to have more contributors, and more $$) and the member’s perspective.

8

Hm, you talk about me ?
If yes, did you see any complaint from my side ?

It is nice that you share your opinion, but please be sure you don’t carry and own my own opinion.

1 Like
9

Hello @rcheesley, thanls you for your explanation.

How can we validate that this contribution is real?
When a company commits resources to Mautic (for example, in the development of a plugin) who is eligible for “Contributing members” status? Is it all employees? The manager? Another person?

When you’re spending time, how do you calculate this? I know that today there’s a tool that counts contributions in Github and on the forum by company. But how do you keep track of what’s going on outside?
Is it purely declarative, based on trust? If so, how can abuse be prevented?

The way I understand it is that the “Supporting members” grade is level 1 and the “Contributing members” grade is level 2 (more involved than level 1). Am I mistaken?

If these are two complementary and non-hierarchical ways of contributing, why not give them the same name and the same prerogatives (the same rights and obligations)?

In my opinion, there are too many different roles. I suggest grouping them all under one name with the same prerogatives.

If a company decides to donate money, then it is entitled to 1 vote per $X donated per year? Or each company is entitled to one vote.

On this point, if the cost is lower on Open Collective, I suggest removing the channel through Github Sponsors to optimize costs. :slight_smile:

Pierre

10

This is one of the biggest issues.
I wanted to propose a slightly meritocratic scheme by means of weighted-voting, but immediately hit the wall of “How to measure contribution” and had to abandon the idea, at least for now.

As you say @pierre_a , we do not yet have a proper method to effectively measure contribution, that is one big reason for me to adopt something less complex, at least in the early days, like consensus.
Consensus requires no technology, not even a vote counting app.
I would really love to see some level of meritocracy implemented as I think it would encourage participation and contribution, but I can’t figure out how that could be properly implemented without spending a small pile of cash. I will keep thinking about it…

11

This would use the existing tools and definitions for contributing. The person who wants to claim this status would need to be able to demonstrate a consistent contribution history in SavannahCRM (which we can verify) in order to be eligible. I think maybe we should be clear about what we look for - eg do they need to show a year’s worth of contributions to be eligible? Or a specific time period? I did not think to make that clear so that’s a good point for discussion.

Here we are talking about individuals rather than companies.

So if the plugin is provided free of charge and is open source, per this term:

then probably we would consider that the maintainers of that plugin (as evidenced by the commit history of that plugin) would be eligible, if they are spending at least five hours a month maintaining that plugin. This would only be the case if that plugin was open source and freely available.

As they would be self-certifying, to a certain degree we would have to take their word for it as to the time that they spend. I’m not up for micro-policing and checking timesheets! :sweat_smile:

That’s a great question. Thanks for raising it!

Currently we don’t actually log the time that someone spends contributing, just the actual number contributions. So it would be on trust, to an extent. I would think that we would review their contribution history and see whether that actually matches up with what we would expect to see from someone who has been contributing five hours a month consistently (which is roughly one hour per week). Obviously we have some tasks which take a lot longer than others, but we’re working on ways to try to adjust for that (eg breaking down into smaller tasks).

Maybe this would be better represented as a physical number of contributions, but that could also be open to exploitation, possibly more than by taking someone’s word that they are contributing.

I guess we have to consider how likely it is that someone would want to cheat the system by making a fake claim to become a supporting member, how easy or otherwise it would be to decide if it was a valid claim, and how we deal with that process.

I can ask the PSF how this works in their community and what the rejection rate is like, if that would be helpful?

No, they have exactly the same voting rights. Nothing at all is different. They are not better than or worse than each other.

It’s purely and simply, a different way to become a member.

So you’re not better because you contribute practically, or financially. Just you become eligible to be a member through a different way. Financially contributing, or practically contributing. The two are not mutually exclusive either. You could decide to pay to become a Contributing Member, even if you are eligible as a Supporting member.

Likewise you could (and hopefully many would) contribute practically to the level where they would be eligible to become a Supporting member, even if you’re already a Contributing member.

I just gave them different names to make it clearer that there are different ways to become a member.

I like your suggestion of just calling it ‘membership’ and having different ways to become a member, without actually having different names for the different types of membership. Totally open to updating the proposal above to just have it under one section and break it out into different ways to become a member. I can draft that in a later post for consideration if that works?

We have not discussed this but I would suggest that we just stick to individuals having the option to vote, not companies. Having companies voting opens up a whole huge can of worms which I don’t feel that we are in a position to deal with right at this stage, but it might well be something that we could consider in the future if there is sufficient need and desire for it.

I’m open for discussion on that, but please just bear in mind the complexity, and potential for abuse, of enabling companies to be involved in decision making/voting.

It’s something to consider. It was only a month or two ago that GitHub introduced fees for companies sponsoring through this route. Some orgs and individuals do like to have the kudos on GitHub of sponsoring projects, and it is quite the process moving everybody over to a different system. So this would be something we would have to discuss with those sponsors and decide if this is the right time to cause that disruption (but I would also love it if everyone sponsored on Open Collective as it makes it much easier to do the open startup reporting too!)

1 Like
12

SavannahCRM only measures quantity, not quality nor duration. Hence it is not a valid verification of anything, just an indicator of activity, number of contributions, that is.
So if I add 5 PRs in 10 minutes in Github, I get 5 points.
If I dedicate 4 hours to research an article, I get… 0 (ZERO) points.
If I finally publish said article, I get 1 point.

13

This is not entirely the case. The way that we can use Jira means that we can (and indeed, should, for the reasons you have outlined) separate out larger tasks into smaller ones, and tackle those ones individually. We could for example give guidelines that any task over a certain anticipated duration would be advised to break apart into separate tasks for this reason.

We are trying to do this currently but we could make it more consistent by having clear guidance on this topic. I feel that would largely address those concerns, when used appropriately.

Of course this, like anything, is open to exploitation, so we would need to ensure that it is being done correctly.

14

Of course, and we could just “manually” evaluate each contribution and give it a “value”.

15

This is EXACTLY the case. I asked the software owner/developer.

16

I meant that you were not taking into account in your explanation the way we can use Jira to break down tasks into smaller sub-tasks, so that if something takes a really long time, you actually get credited for the work by completing all of the smaller tasks. I was not referring here to your comments about Savannah CRM and how that works.

18

Following up on the questions about the Fellows, which I took inspiration from the Python Software Foundation, I went back and asked a bit more about how it works and how the folks who receive the award and the community feel about it.

With Python being a very long standing project since the 1990s, they have a lot of people who never received credit at the time for extensive amounts of contribution, because there were no mechanisms back then to give people any tangible thanks for all the foundational work they had done back then.

The PSF award maybe 20 fellows per year on average, and many are working through recognising historical contributors, but sometimes they are people who have contributed substantially but their career path has changed and therefore they’re no longer involved actively with contributing to the project.

I asked if those folks who become Fellows value it, and my understanding following conversations was that they don’t really care about having voting rights for life - some use it, some don’t. They do, however, feel very proud to be recognised as having made significant contributions to the project and being recognised as a Fellow is something that they cherish and value. The community see that as a sign of respect - someone who is a Fellow has made a significant and sustained contribution, much like we talked about in the Governance Working Group slack channel about ‘elders’ of the community, and their voices can sometimes be helpful in bringing different perspectives.

Now, obviously we are a much smaller project and much newer. I would envisage we might have 2-5 people that we could consider for this status from the outset. Maybe a few might be nominated per year.

I would think that might include for example, folks who have been fundamental in creating Mautic but aren’t involved - our founder DB Hurley, Alan Hartless who is one of the principle engineers who built Mautic, and so forth. I expect that some of the longer established community members might be able to nominate a few more.

Hopefully that might be helpful as a bit more context around the suggestion of that type of membership. As mentioned above, I’m happy to look at maybe changing the name if folks feel it’s not appropriate, or even removing if we don’t think that it’s necessary to recognise past contributors in this way.

The below still holds for the importance of this type of membership to me.

Would love to hear thoughts on this.

19

Looping back on the discussion of membership types:

  • I can’t think of any reason why we would ever want to distinguish between the types of membership other than ‘is member’ and ‘is not member’ or ‘member’ and ‘fellow’.
  • I’d be happy to get rid of the membership types (1.1 to 1.3) and just have it all under the title of ‘Becoming a member’ if this helps to simplify things, and makes it easier to understand that one isn’t better than the other.

@pierre_a would that bring this section to a place where you’d be happier with this part of the proposal?

20

Some thoughts I had when reading this:

  • Why even allow people to decline its right to be a Mautic member? It doesn’t make sense for someone to not be a member if there are no rights or obligations attached to it. Similar trend, but keep it as simple as possible. Let the code of conduct be the arbiter of the behavior.

  • Supporting member. It’s not fully clear when the price is revised once a year. I suggest to limite to X countries or regions. You already have enough administration I would think, so I’m not sure why this should be more complex than necessary.

  • Contributing member. To me it’s a bit odd to see “5 hours” as a requirement. This is not really a standard within Open Source communities afaik. I understand you want to set a minimum-bar, but maybe make the case that they should provide proof of 5 positive contributions to Mautic in the last 3 months? I could easily spend 5 hours thinking about Mautic and replying random things but not really contributing to the project in general. I would challenge this and see if we can rethink this towards something that can be more easily measured from the outside instead of “believe me on my word”. Ideally this becomes an automatically granted role through community platform analysis or by setting some basic measurements in place such as code commits and you manually audit the non-code contributions until you have a better system

  • Managing members: There is a small sentence about that, but no header.

  • Fellows: In most other OSS projects this is called “Core team” or something similar. Given you require a vote, what happens if members of the community council do not show up or from the chartered working group? Do you then postpone the decision until the year is over per “A voting member who does not cast a vote for one (1) votes within a single calendar year shall immediately have their voting rights revoked for the remainder of such year.” I suggest to turn this around, if no objections are given for the member to become a fellow or core team member within 30 days, we’ll move forward. Someone can only become a fellow after being or have been a contributing member. A bit later you refer to lazy decision making so why not follow your own principles?

21

Notes from Gabor on Slack:

  • “Contributing members” are same as “managing members”? The name seems to change mid section. Important because the benefit (voting for free) only comes at the end.
  • You may want to have a way to revoke Fellowship in rare and extreme cases. Maybe 1.6 applies to fellows but that is not clear.
  • The voting rights also seem to be responsibilities if voting rights are revoked following not participating in a vote. That should be considered carefully. Ie. if someone goes on vacation, could they loose their voting right for the rest of the year? Especially for 36 hour votes.