Who approves?

Continuing the discussion from Rearrange profile page so important fields are at top:

I think there is something wrong with this process, or maybe it’s just the way that it has been explained.
Any little change could be a Pull Request. Any petition could be a little change. What is the dividing line between arbitrary small changes (especially to the UI) that the community should approve or the core lead should approve?
Do we need some input from a designer or accessibility person before UI changes happen?
Should any petition with a PR be accepted, or do you need votes?
There were quite a few of the original petitions that had votes and were determined to be plugin territory and subsequently closed.

Now that the widget in the dashboard shows the petitions and their status, it is disheartening to see the erosion of the democracy. It feels like WP again.


I share these concerns. It should not be possible for just a few people to get something changed just by being noisy. I have mentioned the accessibility issue with this at least twice now and have yet to receive any responses.

On the other hand, I don’t think it’s right that one person should have a veto. Rather, I’d like to see those making proposals try to build something approaching consensus. If we’re a “community,” let’s act like one.


The process has some issues

And with the process I mean the ideal, not the factual one.

De facto if we do things by majority we would need to know what a majority is.
We can’t, as we don’t have a registry of voters and thus can’t know what a majority is.

Even if we could, it’d mean that plain simple because 51% (or whatever we’d decide to be the majority requirement) could want a very “bad” feature to be implemented or deny a visionary feature just because not understanding it fully.

And even if we could solve all that, we’d remain a dictatorship of the majority (also known as mob rule or ochlocracy), and the minority (even if a whopping 49%) would have to accept a feature they don’t want. I think Gutenberg is a cool example of such mob rule. The majority of the users actually likes it, at least judging from the many forums and groups I’m member if, but a massive amount of users do not. Yet it’s not the majority. The majority would be 31 million websites owners at least. And even with all the noise against Gutenberg I don’t think that’s the case.

This is a problem of democracy, not of classicpress.
And we shouldn’t try to solve what humanity has tried to solve for the past 5000 years and has blatantly failed so far, calling presidential republics democracies and dictatorships “rule of the people”.

Instead I think we should try something different

I believe a good solution can be found if:

  • we adhere to our technical requirements, guidelines and norms. For example, there can’t be a breaking feature in a minor release. There also can’t be a feature braking accessibility. There can’t be features putting the system or the user at risk.
  • we strive for perfection. Perfection isn’t an opinion. It’s a state of how something performs it’s task with the least effort, and the least flaws without unrequired addon.
  • we let the makers have a opportunity to push their work. This means, if someone works daily with the tool and has an improvement ready to go that doesn’t speak against any of the above, it should be painless to push it. This doesn’t mean just because i did all the work to integrate SVG upload in CP I can just push it, unless I can also guarantee the tool stays safe and is not compromised by the feature

The voting process itself is meaningless unless it has zero votes (no one who is willing to even share opinion wants it), unless we add a “no” vote, in which case still all above points must win over the vote result.

My points above at far from ideal and I think we should continue and refine this trying to set up a sort of “the 3 laws of robots” by Asimov - meaning that we set a group of rules that make the decision for us.

Like the technical boundaries, which cannot be broken, should already help resolve a majority of the decisions.
Even design ones, if we formulate these rules in a thought through way and “unmask” the design aspect into a technical one, I believe mostly well not struggle making the decisions.

The Petitions are still value adding specifically as a tool to “initiating the process” and refining a thought to become reality and get a general feedback on “how much something is wanted/unwanted”.
However as a strict opponent of the democratic process per se, since endlessly flawed and typically conceited in the sense that the belief “the broad public is actually able to judge a situation and make a decision based on votes of mostly unaware humans” is omnipotent in a democracy, I don’t see the petitions as an instrument to actually make decisions based on. Neither here, nor IRL. Nor should single individuals, of course - which is why I believe with a wells defined, based on facts and norms set of rules we will be able to circumvent this problem.


Beda, while I do agree with most of what you said, my concern was about the split between a petition and a PR, having two places to look, and having whoever was given moderator rights on the forum the ability to basically promote the petition because it has a PR.
The process needs some definition, and votes against would be a good way to start.

1 Like

Changing petition status to pull-request or cp-research-plugin doesn’t mean it’s approved. It simply means someone is willing to put the work in and see if it’s feasible.

If either one gets approved and slated for inclusion into core by the core team/James, then status changes to planned.

Until petition is marked planned, nothing is approved and can be declined/rejected at any time.

For example, TinyMCE research plugin can be rejected completely. It hasn’t been approved for core inclusion, it’s just a research plugin.

Also, refer to our Governance page for more details.

Any suggestions for changes to the process can also be opened as a petition, as petitions are not limited to core. They cover everything related to ClassicPress.


Agree with the others, generally speaking.

About the petition labels, though…

If something hasn’t made it through the “planned” stage, it should never reach the “started” stage – it should simply remain unlabeled. This implementation is confusing.


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 @anon66243189 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.