WordPress Community and Redress of Grievances

[chipbennett]

WordPress is a SABDFL*-directed project in which essentially all decision-making is top-down, yet at the same time, is a project that accepts community contributions and strives to build a community around itself.

While I do not want to get into the merits of being a SABDFL-directed, top-down decision-making project versus a community-directed, bottom-up decision-making project (since I have no inherent problem with the former), I do want to open a discussion on how community contributions are handled.

Consider the most conspicuous community contributions: plugins and themes.

The WordPress.org website provides an excellent service to and opportunity for the community, in terms of its SVN repositories for third-party plugins and themes - repositories that tie directly into WordPress, and for which update functionality is built into WordPress core.

Further, the WordPress.org website provides fairly explicit conditions under which plugin and theme contributions are allowed to reside in those repositories.

All great so far, but what happens when something goes wrong?

In the past, there have been complaints that repository approvals have taken an excessive length of time. Especially controversial was the single-handed removal of some 200 themes from the repository.

But let's look at two fairly recent (and decidedly less controversial) incidents, both involving the removal of plugins from the repository.

In the first incident, a plugin author forked an existing plugin, only to discover that his plugin had been removed from the repository without warning or explanation. Once the plugin author was able to find the right person, he pressed for an explanation, and discovered that the plugin had been removed due to an alleged security vulnerability - a vulnerability that existed not only in his plugin, but also in the original plugin from which it was forked (but that was not also removed from the repository, even though it had the same alleged vulnerability).

In the second incident, a plugin author had all of his plugins removed from the repository, due to clear violations of the guidelines for repository-hosted plugins. The plugin author, after much discussion, decided to modify the plugins so that they would no longer violate those guidelines, but was told that under no circumstances would his plugins be allowed back into the repository.

My points of contention, in both incidents, are that:

• Neither plugin author was appraised of the offending nature of his plugins prior to removal
• Neither plugin author was given any warning before his plugins were removed
• Neither plugin author knew exactly whom to contact regarding the removal of his plugins
• Neither plugin author had any official means to appeal the decision to remove his plugins

The WordPress project simply has no formal means to address any of these contentions.

It would appear that moderation of the repositories falls on the (likely over-worked) shoulders of one person, and that decisions are made far more subjectively and arbitrarily than objectively and according to explicit guidelines.

My suggestion (subject to discussion and modification) is as follows:

1. Implement a Community Contribution committe, that will oversee the guidelines for all community contributions, including plugins, themes, core patches, documentation/codex, etc. This committee would also oversee the marketing and communication of the various means of community contributions, and would champion and facilitate such contributions.
2. Implement a Community Conflict Resolution committe, that will oversee all complaints about community contributions, make all decisions regarding actions taken against community contributions/contributors, and handle all appeals of those decisions.

How would such a committe structure have helped handle/resolve the two incidents in question?

Let's take Alden's case (the first one):

• The person alleging the security vulnerability would have reported the allegation to the Community Conflict Resolution committee.
• The Community Conflict Resolution committee would have notified the plugin author of the allegation, and provided options for resolution (and recommendations for where to seek help if needed - IRC, wp-hackers, etc.).
• The plugin author would have the opportunity both to act on the allegation, as well as notify the committee that the alleged vulnerability came from the original plugin - giving the committee the opportunity to notify the author of the original plugin about the vulnerability, as well.
• Both plugins would have been patched, more quickly, with neither plugin being yanked from the repository and with neither plugin author being offended.

Let's take a look at Pawan's case (the second one):

• The person(s) making the allegations regarding the plugins would have reported the complaints to the Community Conflict Resolution committee, which would have provided a more specific entity to whom to complain than merely posting in the general wordpress.org support forums.
• The Community Conflict Resolution committee would have notified the plugin author of the complaints, and provided options for resolution.
• The plugin author could have challenged the complaints, based on the current wording of the guidelines.
• The Community Conflict Resolution committee could then have consulted the Community Contributions committee regarding those guidelines.
• The Community Contributions committee could then have clarified/revised the guidelines, to make them more explicit
• The Community Conflict Resolution committee could then have addressed the plugin author's appeal, again providing options for resolution.
• If the plugin author had still not chosen to resolve the comlaints, the Community Conflict Resolution committee could have decided to remove the plugins from the repository.
• Had the plugin author then later decided to resolve the complaints, he could have appealed to the Community Conflict Resolution committee to have his plugins reinstated in the repository.

In both cases, the incidents would have been handled in a far more clear, fair, objective, and desirable manner:

• Neither plugin author would have had plugins removed from the repository without warning and without being given opportunity to rectify the cause for removal.
• Neither plugin author would have been left without any recourse to appeal highly subjective and arbitrary decisions.
• Both plugin authors would have known exactly whom to contact regarding the incident in question.

Thoughts?


* Self-Appointed Benevolent Dictator For Life (see also: Ubuntu Linux/Mark Shuttleworth)

[brandingdavid]

I do think though that during the whole process, while the plugins shouldn't be removed, the option to download them should, at least until a final outcome came to pass. A message to the effect of

"this plugin is currently undergoing evaluation, if this is your plugin, and you've received no message, please go here"

That way information regarding using the plugin, finding support, and other issues that current users may have could be still handled on WP.org rather than having people go to unscrupulous 3rd party sites to get "upgraded" versions of the plugin or theme.

Also, while I think your idea is good, I think it definitely needs some more detail and refinement. I look forward to seeing everyone else's responses. (side note: doubtful that this will ever come into play though)

[chipbennett]

I do think though that during the whole process, while the plugins shouldn't be removed, the option to download them should, at least until a final outcome came to pass. A message to the effect of

"this plugin is currently undergoing evaluation, if this is your plugin, and you've received no message, please go here"

That way information regarding using the plugin, finding support, and other issues that current users may have could be still handled on WP.org rather than having people go to unscrupulous 3rd party sites to get "upgraded" versions of the plugin or theme.

That is a great suggestion, though it more deals with implementation (the "how") of the idea - and I'm still very much in the "what" phase.

Also, while I think your idea is good, I think it definitely needs some more detail and refinement. I look forward to seeing everyone else's responses.

Very much so - that's the intent of this thread! :)

This is very much a fledgling idea. I'm trying to lay out the rationale for why something is needed, and get feedback on what it is that should be implemented.

(side note: doubtful that this will ever come into play though)

Call me eternally optimistic.

I wanted to make sure up front that I differentiated between the suggestion of implementing a WordPress project-related decision-making committee (which I'm not suggesting) and the suggestion of implementing committees for handling community-specific issues.

I'm hoping that the powers-that-be realize that the two suggestions are entirely and mutually exclusive of each other, and will consider the latter suggestion on its own merits.

The larger the WordPress contributor community gets, the more issues will come up, and the more difficult it will become to deal with those issues by one person (or by a handful of people).

[Ryan]

My suggestion (subject to discussion and modification) is as follows:

1. Implement a Community Contribution committe, that will oversee the guidelines for all community contributions, including plugins, themes, core patches, documentation/codex, etc. This committee would also oversee the marketing and communication of the various means of community contributions, and would champion and facilitate such contributions.
2. Implement a Community Conflict Resolution committe, that will oversee all complaints about community contributions, make all decisions regarding actions taken against community contributions/contributors, and handle all appeals of those decisions.

How would such a committe structure have helped handle/resolve the two incidents in question?

How about the following:

1. Matt appoints someone to oversea the repository
2. The appointed person starts telling us what's going on

So basically, continue with the current system, but when new situations like this arise, just let us know what is going on (perhaps via WP devel or some other official channel) and why some of these actions are taken. This would ensure that others don't inadvertently fall foul of the repo. standards.

Creating committees just breeds bureaucracy and something like plugin approval doesn't seem like something that needs a layer of bureaucracy placed onto it.

I don't think the current system is broken beyond a lack of information flow. Creating a committee won't necessarily improve information flow.

[chipbennett]

How about the following:

[*]Matt appoints someone to oversea the repository[*]The appointed person starts telling us what's going on

So basically, continue with the current system, but when new situations like this arise, just let us know what is going on (perhaps via WP devel or some other official channel) and why some of these actions are taken. This would ensure that others don't inadvertently fall foul of the repo. standards.

Some things can be handled by one person; some can't.

I would much prefer that Matt appoint the members of the committees, and then let the committees act mostly autonomously.

Thus, if the Community Contributions committee wants to appoint one person to oversee the repository, then so be it.

Ideally, the committees would be comprised of community contributors, and not just "official" contributors. The point, of course, being that the community would have real influence (rather than lip service) in setting the rules for community contributions - while still leaving the direction of the WordPress project itself squarely and clearly in Matt's hands.

Also, an important part of the suggestion is having two clearly separate committees: one to set the rules, and one to deal with conflicts. That separation removes much of the subjectivity and arbitrariness of decisions that get made in resolving those conflicts.

Creating committees just breeds bureaucracy and something like plugin approval doesn't seem like something that needs a layer of bureaucracy placed onto it.

Not necessarily. I agree that multiple people don't all need to approve plugins - but having multiple people capable of providing the single approval that is needed would be a good thing. A committee isn't needed to approve plugins; however, having multiple people authorized to do so might certainly improve the process and remove some of the burden from the one person currently responsible for those approvals.

Committees do not always "just breed bureaucracy".

I don't think the current system is broken beyond a lack of information flow. Creating a committee won't necessarily improve information flow.

I disagree.

Information flow alone would not have prevented Alden's plugin from being removed from the repo.

Information flow alone would not have led to the decision not to allow Pawan to resubmit his modified plugins back into the repository.

[brandingdavid]

Even two or three people could act as the committee, helping this process along, and stopping many of the issues that currently occur. It doesn't have to be a big crazy mess...

As for your idea being in the "what" phase... I think you got it nailed down pretty good. The real hook of the idea though, like Ryan mentions, is the idea of shared information, which currently doesn't exist, as well as your great idea of not taking actions before developers have a chance to re-act. Thus basically assuming they are innocent of any mal-intent and giving them a chance to change whatever needs changing.

[chipbennett]

Even two or three people could act as the committee, helping this process along, and stopping many of the issues that currently occur. It doesn't have to be a big crazy mess...

Absolutely!

As for your idea being in the "what" phase... I think you got it nailed down pretty good. The real hook of the idea though, like Ryan mentions, is the idea of shared information, which currently doesn't exist, as well as your great idea of not taking actions before developers have a chance to re-act. Thus basically assuming they are innocent of any mal-intent and giving them a chance to change whatever needs changing.

And, again: absolutely!

While information flow alone cannot and will not address all issues, it is a key component to what I am suggesting. In fact, it is one of the two or three key components (information flow, community input, objective decision-making).

[WPblogger]

I think this idea is one of the better suggestions I've seen in a while on how to deal with these situations.

Things right now are too arbitrary & open to personal agenda's, favors, etc. The fact that a forked plugin is removed while the original stays despite both having the same problem is a strong indicator that something has gone astray in the process.

I think a 3 person panel for each side of things would be fair and largely avoid creating a lot of bureaucracy.

However, in the end, this entire idea hinges on the people currently controlling everything being willing to give up any power or control. It's fine that you're optimistic but I don't think we've seen any evidence to suggest they'd be willing to do that.

[chipbennett]

I think this idea is one of the better suggestions I've seen in a while on how to deal with these situations.

Things right now are too arbitrary & open to personal agenda's, favors, etc. The fact that a forked plugin is removed while the original stays despite both having the same problem is a strong indicator that something has gone astray in the process.

I think a 3 person panel for each side of things would be fair and largely avoid creating a lot of bureaucracy.

However, in the end, this entire idea hinges on the people currently controlling everything being willing to give up any power or control. It's fine that you're optimistic but I don't think we've seen any evidence to suggest they'd be willing to do that.

Quite frankly, if the powers that be won't even consider such a suggestion, then the whole concept of a WordPress developer community will eventually just go away.

Right now, sometimes it feels like "all your code are belong to us" - the project willingly accepts code contributions, but no input on project decisions or on the handling of contributor community issues.

It will eventually devolve into an environment in which developers will move on to other platforms, because they no longer want to deal with the from-Mount-Sinai decision-making or the capricious and arbitrary handling of issues and conflicts (not to mention, the disparate means if disseminating information that affects the community).

[Otto]

I got your "Redress of Grievances" right here, buddy!

*POW right in the kisser!*