Greg Knaddison directed a session on what we like or we don't. He solicited comments on what confuses and what bugs folks. These are my notes from that session.

The Drupal community is represented by a diverse community comprised volunteers who are paid or hope to be paid.

Releases occur at the speed they do as Dries was worried that the CMS would fall behind other projects. The idea is to stay ahead of the curve. Dries worried that things would go stagnant. Sometimes folks complain about having to upgrade too often, but it was brought up that you could jump over one major release. In the case of Drupal 6, this may have been a problem as 4.x has dropped off being supported but not all important contrib modules had/have been brought to a final release there are challenges.

So, when will "it" be ready? (where it is core, a contrib module, etc) It is ready when it is ready! But you can help even if you are not a coder or themer! You can work on documentation and testing. Work through the issue queue! Find things that are duplicates and close out the duplicates. The maintainer will love you.

Who decides what in Drupal and why does chx decide so many things in Drupal? It is a do-ocracy. He decides BECAUSE he decides so many things in Drupal.

How do I find out what will be in the next release? So, where do I find the roadmap? There isn't one. But there are predictions that can be found in places like the forums. Different contributors have different battle plans that outline what they would like to see and what they think they will work on in the next full release.

Why are there major changes in every release that break the API? It doesn't make sense that upgrading core should break the modules I use! The Drop is always moving. People don't break the API on purpose, so to speak. But there has been a decision to not let the old API determine the path for the new API. Data should ALWAYS upgrade gracefully but to remain on the edge, old aspects of the API may (and often will) become obsolete.

Why isn't feature x in core? Not everybody agrees on the feature set. Drupal core is small with APIs that can allow for module developers to create modules that do cool stuff!

How do you see if a module will break your site? Test it on a test site.

Don't grump at module maintainers if something doesn't work quiet the way you want/expect or if you find a bug. Be thankful that someone took the time to build something and contribute it to the community. Be polite.

• If you use a module, thank the developer--you will make their day
• If you find a bug, submit the report nicely
• If you want to help, test a patch. drupal.org/patch will give you help on how to do it
• Karma is our currency--when you contribute, folks are more likely to help you in a time of need. However, Karma can be bought. Offer a small bounty for a bug fix. You'll be amazed at how far $25 will go.
• Don't demand things--these folks have provided modules for free
• Toot your own horn a little when you do help

How can I get help with my problem?

• drupal.org/support
• Search first, ask smart questions in the forums and in IRC
• Pay for support

How can I keep track of new developments?

• Issue queue -- RSS feeds can be filtered providing you with a good idea of what is going on
• Use the mailing lists, drupal.org/planet, forums, groups.drupal.org, and IRC

How come there are so many modules that do the same thing?

• Remember that Drupal is a Do-ocracy. So Do-ocracy + Different goals = multiple modules
• There is a desire for credit--creating a module is one way of getting it
• Finally, a module may start out being divergent from another but over time, patch by patch incompatibilities at one point go away leaving more than one module that do similar things

Finally remember that "Contributions are Gold" and not all contributions are code. Contributions can be advocacy, patch testing, documentation, de-duping issue queues and so much more. The more you contribute to the Drupal project, the more you will get back.