The Drupal project is growing and needs to have dedicated channels of communication to non-traditional contributors to the Drupal project. These non-traditional channels include businesses that are not familiar with how open source communities work. Press that is looking to validate information about the project. Advertisers looking to understand how to get a book ad, make use of Google Adsense, or participate in the advertising and affiliate program. PR firms that are looking to add valuable marketing case studies and press releases to the marketing assets of the Drupal project. Businesses that would like to be listed in the Drupal services page, but aren't familiar with the Drupal meritocracy. Bloggers who want to be part of the Drupal marketing efforts.

We need a project managed by individuals who understand that these type of users don't respond well to "Prove you are not a spammer" and RTFM. In short, we need to understand this new audience and embrace them.

Thoughts? Volunteers to manage this project?

Comments

keith.smith’s picture

keith.smith commented

I'll be glad to help, but let me make sure that I understand what I am volunteering for.

You're talking about creating another project with an issue queue that could be monitored by a number of community ombudsmen who could triage issues into the correct queues, or either deal with the issues themselves, in a responsible, positive way that doesn't presuppose the original poster has any knowledge of the community? You'd try to front-load the queue by making sure the direct link to posting issues is posted prominently. Or have I misunderstood your post?

Comments:

  • Of course, there will always be people in the groups you mention above that will post in the "wrong" place, or not know this queue exists.
  • When you say, above, "dedicated channels of communication", it makes me wonder if I've misunderstood. Just as the people this queue is built for will post in the wrong place, people outside your target group will post in it, especially if it has a friendly sounding name like "Community relations".
  • How are contact form categories like "Press inquiries" handled now, and do you see this issue impacting that process (or that of the other public relations categories on that form)?
  • Obviously -- and I know that you're not recommending otherwise -- everyone should always be polite to everyone, whether they are a representative from a marketing firm or not. We can't enforce this, but can only try to improve it. This also means that while we can make a concerted effort to be polite and helpful in a special queue, we also can't enforce it there.
  • Another queue similar (in my head, at least) to what I imagine you referencing here is the "User experience" queue. Unless I run across an issue from there on the top of the tracker, I don't really use that queue much myself, but perhaps that's just me. I see people "cleaning it out" every month or two, which makes me think there's not a lot of traffic there, though. Obviously, any proposed queue does not need to add a lot of time to a ticket, and extra layers of people processing always brings that danger.
  • In a non "open" environment, say, my business, my "internal" queues are different from my external ones, and I would use a different language internally, a different form of verbal shorthand. I wouldn't be embarrassed if someone saw my internal notes, but I usually don't write them for direct public consumption. Separating the public relations of managing requests from the mechanics of accomplishing the tasks (in a more direct way than what I think you are suggesting here) may also help, but may be inappropriate for an open-source project. (Although obviously some of this happens now with dedicated sites for infrastructure and security.)

I'm really just writing notes as they come to me, and don't mean to suggest that I think this is a bad idea, by any means.

Amazon’s picture

Amazon commented

Keith, correct I am suggesting we have a new project on Drupal.org. That project should have an issue queue. I am not suggesting a new meta level queue for triage, just a business and marketing project.

Yes, queues will be misused. That's understood.

Politeness is not really the point of the new project and issue queue. The current maintainers are plenty polite and do a fine job. The goal of this new project is to build business and marketing assets for the Drupal project. That means this new project and issue queue is specifically intended to grow advertising, grow press relations, grow case studies, grow relationships with PR firms, increase the number of bloggers blogging about Drupal, increase the number of valid businesses that are known to support Drupal.

The current projects are focused on maintaining quality of Drupal's assets like Drupal.org, and ensuring quality contributions to pages like /drupal-services. There's a lot of great work going on there, but it's work that focuses on preventative quality control. We need a project that focuses on proactive service to target audiences we are trying to grow.

For instance, we have issues and project maintainers that are specifically targetted for GHOP students. High school students are treated differently and everyone agrees that it's important to meet that audiences needs. We have projects and issues that are specifically targetted at security and security issues. Again, security issues and security reporters are treated in a certain way to meet that audiences needs.

I hope that clarifies.

Kieran

keith.smith’s picture

keith.smith commented

Yes, it does. That's very helpful. And indeed, I had misunderstood several key elements about your original post.

With a new understanding about what you are proposing, then yes, certainly, I'd like to help.

tvn’s picture

tvn commented
Status: Active » Fixed

Cleaning up old issues.
There is now http://groups.drupal.org/marketing-drupal and issue queues:
https://drupal.org/project/bam_mission
https://drupal.org/project/bam_branding
https://drupal.org/project/bam_research
https://drupal.org/project/bam_infrastructure

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.