As you may know, I have been extremely frustrated lately with the ways in which the webmasters issue queue is currently being handled, specifically, I feel that some members of that queue are not open to the opinions of the community at large. At the moment, it doesn't matter what your involvement in Drupal is, nor does it matter whether you are an expert in the domain where you are trying to help, the only thing that many of the more vocal members of the webmaster team care about is whether you are a webmaster. I can't think of another issue queue on Drupal.org that works in such an insulated way (and very often hostile and dismissive), and so I'd really like some clarity on what the community at large can expect to be able to do to help with d.o. if they aren't "webmasters" (esp. since it seems like new webmasters are hardly ever approved, at least in the issue queue)?
If non-webmasters are not welcome to help with the d.o. content/marketing/outreach/vetting tasks that are currently "owned" by the webmasters then I suggest one (or more) of the following:
- removing those items from the webmaster issue queue
- stop asking for the community's assistance when the limits of such an insulated and opaque system become too obvious to ignore
- Define clear roles for community members who are not webmasters to contribute, and specify the limits and the reasons for those limits
Comments
---
Removing from the site maintainers queue tasks that must be done from site maintainers doesn't make sense; those tasks should be in a queue that is visited from site maintainers (differently, they would not know what tasks are pending).
If the suggestion is that those tasks should be done from somebody that is not site maintainer, then that doesn't make much sense either. Most of the tasks done from site maintainers are done from who has specific Drupal permissions (most of them are administer xyz permissions); if those tasks would be done by somebody that is not a site maintainer, they would still be done from who has administration permissions (in other words, who makes those tasks would be a site maintainer under a different name).
Okay, explain the redesign...
I helped with quite a few tasks during the redesign, as did a bunch of people that work for me, and none of them had to deal with the webmaster's queue. If I had known that I had to be a webmaster to continue helping, I never would have helped personally, nor would I have shelled out thousands-of-dollars to pay my staff to help (which I continue to do via the Git migration, and which I've currently offered to do for the marketplace, which is obviously not going to happen).
Also, I think that in general your comment displays the attitude I feel is problematic, eg having a permission to execute a policy doesn't mean you have, or should have, the right to decide up on the policy. It also shows a basic lack of trust in the general community, which is much larger than the webmasters team.
At the moment I feel the need to warn the rest of the community about the webmasters queue, and also to warn them against helping out too much with d.o., since the help doesn't seem like it's wanted under non-urgent situations, and thus shouldn't be given in urgent situations either (you can't just empower the community when it suites your immediate aims, and then disempower them when it's convenient to do so).
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
---
A group who executes a task can decide the rules to follow to be sure every member of the group does the task in the same way.
What you say is unrealistic.
As you see the issue as something site maintainers versus the rest of the users (which is the wrong way, as already reported you by Michelle), let us remember that so far you are the only no-site-maintainer who expressed such opinions. Your concept of community needs to be reviewed; if the site maintainers don't express the desire of the community (like if they would not be part of the community), then the same is true for you, a single user.
Let us see the original problem, then. It happened something you didn't like, and you now pretend that what you don't like is also something that all the Drupal community doesn't like.
Funny!
Three people in this group voted down this discussion. Too bad you can't delete it- it aint going away until it's resolved, so no need to "vote it down".
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
---
That is not true.
Anyway, are you worried because somebody has a different opininion? I thought that they can express they negative vote in the same way you express your opinion.
FYI, also users who are not member of this group can vote on this group content. Who down voted can be everybody, including who is not site maintainer on drupal.org, or on groups.drupal.org.
Hi Alex - I'm not super up to
Hi Alex -
I'm not super up to date on what exactly is managed by webmasters queue other than vetting what goes on the front page, and managing spam/user accounts, and user roles...
Can you be more specific about what types of tasks that you had these issues with? Might help others to chime in here with some more useful feedback.
Thanks!
Sure
First, I would have responded sooner, and in fact was in the middle of posting a response, when Gerhard banned me (shows me who the boss is!). I lost 30 minutes of writing to you and was called a 'Drama Queen' by Heine for complaining biterly, but I guess it was worth the frustration to get such a blatant illustration of the random abuses of power that seem prevalent with some site Admins. But I digress...
There are several tasks that the webmasters currently assume responsibility for, and for which non-webmaster assistance is either not welcome, or is openly resisted. They are:
For the planet and the services section I went through and reviewed each item, noted which of them had met all of the standards for inclusion in these community spaces, and marked them appropriately ("needs review" for items without another +1, "RTBC" for items that had a +1 already). I obviously couldn't add the feeds myself, but I certainly could have posted new companies to the handbook section, but I didn't. Instead of looking at this as helpful, a couple of webmasters decided that I shouldn't have a say and started to change all of the statuses I created (thus undoing the hours upon hours of work I had done).
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
---
To report what really happened, Alex UA was said he should not change the status to RTBC before two site maintainers gave their +1 for adding the company to the Drupal services list. Nobody told him that he should not give his +1.
As the status was not considered RTBC, it has been reverted to needs review. If his comment was ignored, then the status of the issue should have been reverted to active; as far as I remember, that is not what happened.
The status of an issue report is changed; it is not created. I don't believe Alex UA took hours upon hours just to change the status of an issue.
So the limit is...
you can feel free to comment, but your opinion/review/work isn't going to change things one way or another (unless you are way more persuasive than I am), unless someone makes you a webmaster.
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
---
It is totally untrue.
Thanks for the response Alex
Thanks for the response Alex (no worries about the delay, sorry to hear about the drama that ensued from this being brought up). That helps give some context to the discussion.
It's a fine line - I think it's important for some of this content to be moderated by "not just anyone", though I think it's also important to have transparency and allow anyone to add their opinions/reviews to any issues as well.
The first point you mention:
"Content policies for various places on Drupal.org, including the items listed below are, apparently, the sole domain of the webmasters, but this also includes any item that they decide to lock down via "bumping the input format" to something higher than documentation"
That is actually one that really interests me - we discussed this a bit at the extended Docs Team leadership meeting in December, especially in relation to relying on both the Docs and Full HTML input formats as a method of "locking down" pages. This is a problem because it has the side-effect of restricting use of certain input formats to "trusted" users (ie. someone we may not want to give access to a high level page, by default can't embed images either, which is unfortunate).
Also, I think it's really unspoken and untransparent that these pages are "locked" to community editing, and I'd like for there to be a much clearer process/guideline for this. I've suggested a core conversation about whether to have some "essential" or core docs pages that are restricted to editing by anyone (I realize this is hugely controversial), which I hope will shed some light on how to control the content/quality of important pages vs. community open-ness to editing, etc.
Any thoughts on that, I'd love to hear... (you can reply in detail here if you like: http://groups.drupal.org/node/118474#comment-391894)