Wanna come to a BoF about BoFs?
Birds of a Feather, has such a nice ring to it. This way of self-organizing allows people of like minds to flock together in their motley way spontaneously sprung from the confines of the well architected schedule which didn’t quite fit their needs.
It’s a testament to the efforts of conference organizers at DrupalCon that they can field submissions from such a large number of presenters striving to satisfy the needs of thousands of people with wildly popular sessions. In Copenhagen, rooms were filled to the brim with eager listeners, and even afterwards people seek out the recordings of the sessions they missed. It’s an ideal opportunity to broadcast the latest and greatest in Drupal.
But then there’s the fringe. And the DrupalCons provide for that too. Many computing conferences allow for physical spaces for BoFs: Birds of a Feather sessions. A whiteboard is used to mark the available time slots and locations, where people put in their suggestions and find their niche.
Not seeing anything on the official schedule that suits? Head on over to the BoF board! There's now a forum on the DrupalCon website where people are chatting about BoFs already! I really love BoFs, and I think we can even make them better and get more out of them.
Making a better BoF
At DrupalCon San Francisco, I had an epiphany, OK, not a huge one. BoFs kinda suck when you spend 20 mins going around and introducing one another, and then you get into the meaty bits and it’s already over. There’s an alternative: Open Space Technology.
I wanted to show how so-called "non-coders" can make significant contributions to the Drupal project. Probably the quickest way to make friends with a module maintainer is to help out in the issue queue. You can also help out with triage on some of the busiest projects. This requires no coding at all. (Check out the Views bug squad!) After triage, the next things you can do are:
- Try to replicate bugs - are you finding the same problems under the same conditions?
- Download and test patches - does the patch work as expected under your conditions?
Previously in Part 1 - I described how you can simply download and test your favorite modules to make sure they are working in Drupal 7. Even simple modules like "Environment Indicator" have alpha versions available for Drupal 7. That project has no issues for 7.x version. But has it been fully tested? Give it a whirl! If you find a bug, then say so.
In this next part, I have 2 videos which will show your how I apply and test a patch with a GUI; then how I create a new patch. Now we'll look at patches: applying, testing and submitting.
First: What's a patch?
Does the word "patch" sound mysterious to you? Never had a chance to "apply a patch"? or "Reroll a patch"? Or possibly even submit a new one?
Patches are text files they have instructions indicating differences with lines preceeded by a "-" to indicate that a line will be deleted, and a "+" sign to indicate a line will be added. This set of instructions is saved, instead of just making the changes directly. This means you can pass along this fix. By sharing this fix, other people can apply this patch and get the same fix.
When we say "don't hack core" in Drupal, it means don't change the files directly. You can however write neccessary patches, apply and share them. Patches are written to fix a bug, but sometimes can introduce new problems. Because of that, they need to be tested. And we'll see how to do that.
Drupal 7 RC 1 needs testers. And now more than ever, your favorite modules need testing too. As Moshe wrote yesterday, they're here to collect on the D7CX pledge. This is a great way that a new Drupal user can make a significant contribution, and make some friends in the process :)
I was amazed at the most recent DrupalCamp in Ireland that some people I spoke to weren't trying out Drupal 7 yet. I've been using Gardens so much, I adore D7 and get all itchy when I use D6. Come in, the water's fine!
Well, except that many of your favorite modules aren't quite ready yet. Many module maintainers took the D7CX pledge to be ready for the release of Drupal 7. That looks to be in about 7-10 days! There's a mad rush on and even as a non-coder, or a new user to Drupal you can help.
Download Drupal 7, and test your favorite modules. Report bugs and submit patches! It's easy, right? I'll be making a few posts this week to take "the scary" out of testing patches, and show you exactly how I do it. In this post, we'll get D7 up and running, and determine the best way to locate modules which need help, and the specific issues which need testing.
We had 226 respondents to a survey about roles in the Drupal community. Though we pilot tested the survey and honed down the questions, the findings were inconclusive, though we could draw one result. Apparently we use terms like "themer" or "module developer" yet these platonic ideals seem to only exist in our heads. In reality, a person on a team will find themselves handling many roles. In the context of a larger organization, Drupal is one tool in a larger set to be integrated with. In a smaller dev shop, Drupal is again, one tool of many which are used. Slicing up Drupal developers into roles turned into a muddy exercise.
However, there was one interesting outcome. Of the respondents, 203 individuals replied to the open-ended question: "What do you wish you had known when you started Drupal"? It's taken me this long to code and analyze this information so we can make some use of it. I think it can give people within Drupal some insight on how we can improve our welcome mat. And for those who are new, I hope this gives you some good tips and advice!
It sounded like a really simple request: "Is it easy to add a search filter for 'My posts'?".