Who approves?

My two cents on the voting system.
There is more than one side to a petition.

  • dev side: is that feasible?
  • user side (with a general understanding of the platform): do we want it?
  • average joe that knows nothing of the platform but uses it: do I like this?
  • core team: is there someone to work on it? And is that a breaking change?

And many more.

The votes can’t show really if a feature can be deemed worthy of inclusion because they don’t describe the whole situation.

What is more “logic” to me is that we use petitions as a “starting proposal”.

If a discussion arises on a petition, and there is a proposed solution, and someone is willing to put in the time to implement, and it checks all thecnical needs and is compliant to the rules and core team approves of it… Then we can present the petition as “open for voting” - where the votes serve only the purpose of deciding the priority (what order the petitions’ are implemented in core).

Because if we can “check all boxes and rules” it means it is something that sooner or later can get implemented. We just need to decide if it happens in a month or in a year.

Democracy works, when there are discerning rules at the very base of it. A system that works.

As of now petition aren’t really reflecting the community, since there are so very few people voting.

When the process was implemented the general idea was that it would grow fast and reach a critical mass of people/voters. That has not happened, just because we lack the mass marketing structure that permeates WP universe.

And the marketing effort we pushed through is indeed very big if we put the figures in perspective comparing with WP, but nevertheless we are smaller for now in terms of community size.

Obvious, it is better an healthy community than a tarnished ecosystem kept together with money, but the reality is we don’t have the numbers of voters needed to make petitions work as they were intended.

I basically think we have to reflect on our democracy system and update it to work with the real numbers, instead of working focusing on the numbers we may have “someday when everybody will flee from WP”.

It’s that the issue.

True, WP is a mob democracy. At first CP community was convinced that users will flee from WP in flocks. It hasn’t happened. Maybe it won’t happen. CP is just going to grow slowly biting away market share, probably we are going to erode the market share of those little realities that were struggling for their slice with WP at first, then we will be able to maybe notice WP shrinking.

All the petition system as it is now, is based on the premises that we are able to shrink WP by converting a lot of people to CP and it’s not happening the way it was first envisioned.

As @smileBeda says, we need a set of rules to guide democracy, and I think tailoring these rules to what CP really is now is a very good move we can do.


I understand the concern here, but I don’t think this is workable. Often the only way we can plan to implement a petition if someone actually does the work, in which case it has been “started”.

I think the label of “planned” is pretty clear - it means “we are planning to ship this when it’s ready”. Maybe a clearer definition for “started” would help? “In exploration”, “implementation in testing” … something like that.


I’m not entirely convinced of this, honestly. However I will add a couple more bare minimum requirements for democracy to possibly be able to work.

  • There must be a clear group of constituents who consistently vote on the issues.
  • The constituents must be invested in the outcome of the votes.
  • The constituents must be informed: they must have a good understanding of what they are voting on and the consequences of their decisions.

I agree there should be someone that has the “final say”.

I see the process as follows:

The petition is opened, discussed, someone does the job so that it is ready for evaluation and people can vote on the priority (establishing that the ones deemed to be more important by vote count are to be implemented first).
At this point an appointed group of people checks everything out (it might be that it is not implementable as is or that it introduces breaking changes or somehow breaks rules, so it gets rejected/delayed with a reason. Or it could be it is ready and done right, so it can be planned for implementation).
Having this group of people finally checking things ensures every aspect of the petition is evaluated and means nothing is going to be planned and executed unless it really follows all standards needed.

What I would be very attentive is: this group of people doesn’t get to “push” CP where they think it should go. They don’t have “more power” than the other community members. Their decision of rejecting/delaying/planning something only comes from the rules application. Rules that the community agrees upon. This means these people however have two jobs. They vote according to their opinion when petition reaches the voting stage, and they revise everything checking every detail to decide if it gets rejected/delayed/planned.
Sometimes the vote and the decision about the petition might not match.

1 Like

Did this used to be “the committee”? Didn’t we change the structure?

1 Like

Yes, this is currently “the Directors” as changed here: Further changes to ClassicPress governance (July 2021)

Even though the Directors take responsibility for overall supervision, management of required access etc., we have also started a community-maintained list of open projects and the contact person for each project: Currently Active Projects


Yes, this is the way I see it. From what I have observed…

  1. A petition without a PR will never get anywhere.
  2. Making a PR is a way to get people to take it seriously, test it out and decide if they want it included.
  3. PRs can still be rejected.

It might be a good idea to change this if it is causing confusion. Instead of past tense it should be present participle. Maybe “Considering” or “Examining” or “Testing”?


I should add that the process seems to have worked nicely for the example mentioned.

  1. I opened a PR with a possible change
  2. The issue was discussed on GitHub and another option proposed as an amendment to my PR
  3. It was agreed that this would be useful but should be made into a separate PR
  4. That PR will now be actioned, which makes my change unnecessary and it can now be closed

No unilateral decisions were made. Seems like a good result.


Wow, what a confusing thread.

Firstly, “perfection” is subjective, just like “quality” (read Pirsig but don’t take him at face value). And it also depends on the context.

Secondly, here’s a little joke. When is a petition not a petition? When it’s a pull request. Ba-dum Tsss.
Or is it still a petition? Can it be a petition again after being a pull request?
Those closer to the process may have no trouble with this, but to me the whole petition life cycle has become quite opaque.

Finally, just having an upvote is no good. There has to be a downvote as well. Then and only then do you know how many people have reviewed a petition and care about the outcome, and what the balance is between for and against.


That would certainly be very useful. Can it be easily added?

1 Like

The Discourse plugin that we are using to collect votes on petitions is https://github.com/discourse/discourse-voting. It does not support downvotes.

If someone is willing to modify this code to add a downvote then we can incorporate it.

I could also argue that a “disagree” vote doesn’t really add much, and a better way to disagree with a petition is to add a comment explaining why you don’t agree. This will be taken into account before anything is done on a petition.

1 Like

Yes, I get the joke. And it ties it with my first point above.

Petitions are a dime a dozen. It’s easy to start one and it’s easy to come up with all sorts of grand and lofty ideas. It’s also easy to vote on one. What is not easy is doing the actual work.

I now see petitions as more of a “conversation starter”. If it is going to be viewed as anything more, then the whole petition process needs to be made far more rigorous.


It adds the possibilities of having defined thresholds and proper statistical analysis, thus adding transparency to the process.

1 Like

That was my thinking too. Upvotes are counted and reported in the dashboard widget, and can be seen at a glance. Negative comments are much more vague. You have to go through the whole thread to pick them out. But it sounds like it won’t be easy to include this feature.

Of course, how important it is depends on how we view the overall petition process.

Totally agree. Don’t have any ideas how this could be incorporated in the petition process, but I think this should be considered.

And so, a regular user with no dev skills has little chance of seeing his petition approved. Sad, but true.

And it’s even sadder because that would imply that “voice” is not enough.

1 Like

Exactly. This is the intent of the wording on the Governance page:

Once you’ve made your suggestion it will be open to comment and initial voting by the community. Once a general direction is agreed by the community and the contributors to the core code, volunteers are also needed to move the suggestion forward in the form of an example plugin implementation or a GitHub pull request.

  • If a general direction is not agreed, there is no consensus.
  • If there are problems at a code or technical level, the contributors to the core code will make that known.
  • If no developers are available to move the petition forward and finish the implementation at a production-ready level of quality, then it’ll be difficult to move forward.

Otherwise, the petition can and should be implemented.

I don’t see this as sad.

Voice is important, because people here have great ideas that would not have occurred to me in 1000 years. But having an idea is not enough: we have to know if it’s feasible.

Whether the idea is feasible or not is important. There are many petitions that would be great to have but are simply out of scope for ClassicPress, because they would increase the code complexity and the support burden beyond any reasonable expectation of what we could take on today. But having a feasible idea is not enough: we need people to implement it.

Having people to implement the idea is important. This is what we are often stuck on today, but I have seen us starting to build a lot more momentum over the past few months. Still, just having developers who have the skill, experience and time to work on ClassicPress itself is not enough: we have to make sure that we are implementing features that users want, and that work well according to the broader direction and resources of the ClassicPress project.

In this way, all of these perspectives should inform each other, with who approves being a combination of petition creators, voting community members, and core committers. If we try to make changes without considering the perspective of all of those kinds of stakeholders then those changes will not be successful.

I’ve requested the ability to enable downvotes on the main Discourse forums: Discourse Voting - #226 by nylen - plugin - Discourse Meta Please go over there and voice your support, that will make someone more likely to take notice.

I think it’s good that we are discussing how to make the petitions process better. Personally I think all the essential pieces are in place, and it’ll be good to clarify the rules we use to make decisions further.


It might be worth clarifying this process since community members appear to have different ideas about how it works (or should work).

@viktor recently wrote a very good blog article that covers most of it, so I will quote from that.


Anyone can create a petition to make a change to ClassicPress, be it a new feature in the core, removal of a feature, or changes to an existing feature. Once petitions are created, anyone in the community can vote and start a discussion about the petition.

Fair enough. But then note…

There is no specific voting threshold that would automatically warrant petitions for inclusion in ClassicPress core. Instead, we review petitions based on their merits, alignment with the overall direction of the ClassicPress project, and whether or not the petitioner or other community members are able to provide help developing the feature.

So there is no threshhold number that needs to be reached in order for a petition to be accepted/approved/actioned. The only concern for me here is “we review petitions”… who is “we” and how does this review process work?

Then there are various steps or stages outlined. This one should also be noted…

Research Plugin or Pull Request – once someone decides to work on the petition they can either start working using a research plugin (for complex features) or submit a pull request directly to the ClassicPress core repository (for small, simple features and fixes).

So once someone decides to work on a petition they can submit a PR. This doesn’t necessarily mean the petition has been accepted or approved. A PR can be rejected or withdrawn at any stage.

I think the process is basically workable as is. I actually consider petitions to be more like “talking points” now. But I would like to a see a little more clarity around how petitions are reviewed, who reviews them and what they use as their criteria.

1 Like

My attempt at answering this question is above:

It is just an attempt… hopefully that reasoning makes some sense from the perspective of a maintainer.

1 Like

Thanks @james. We were writing at the same time!

1 Like

I read through the thread on discourse, and I understand the general view on not having a down vote thumb etc. So discourse is not going to implement this.
To me the petitions for classic press should have 3 options + , - , and a neutral. With the request that everybody that reads the petition should vote.
This would give a much better representation for the petition. As in 10+ votes is good if ten people read the post. But if 500 people read the post 10+ is not so positive. And there might even be more than 10 potential “do not like” votes that will never be expressed using current the method.

1 Like