Drupal 7 for Production Websites Part 3: How you can help


published by thomas on Sun, 08/15/2010 - 18:58

The release of the first Drupal 7 beta version is very close. The community is working hard on squashing the last beta blocker issues for the upgrade path. Code sprints, such as the Acquia sponsored one in Boston on August 17, are arranged in several places to speed things up.

This is the third and final post in my series about Drupal 7 being ready for productions websites. The previous two covered Drupal 7 Core and contributed modules, see links at the end of this post. This post is all about how all of us in the Drupal community can pitch in and help making Drupal 7 the best release ever.

Who is Making Drupal 7 Happen?

Drupal is a community driven open source project lead by its founder Dries Buytaert. It is being developed by individuals and companies on a voluntary collaboration level on drupal.org. Everyone participates from their own point of view, sharing they skills and experiences. drupal.org is growing rapidly and closing in on one million members.

To help Dries coordinate the Drupal 7 development he appointed Angie "webchic" Byron as his co-maintainer in August 2008, it was a very popular choice within the community. Angie and Dries has since then made a fantastic work driving the project forward.

They have guided the community to where we are right now, on the verge of the release of Drupal 7. Thousands of users have helped with developing, testing and documentation to get it here.

Beta -> RC -> Release

As of writing Drupal 7 is still in alpha, but a beta release is imminent. What is preventing the beta release is mainly the upgrade path from Drupal 6. On this page only one critical beta blocking issue is listed for the upgrade path. A patch claiming to be 100% functional was posted today. However the patch failed the automated testing with 48 exception, out of over 24,000 tests, and is also set to "needs review". Hopefully those exceptions are easy to fix and it will pass the test as well as reviews soon.

When it does, there isn't much preventing Dries and Angie from announcing the release of the first beta.

The beta release will mean that API's are frozen and the work goes into fixing remaining bugs, getting more documentation done and any other tasks needed attention. For contributed module developer, as explained in part 2, this means they can really start working on either porting existing or developing new modules.

Currently, August 15, the issue queue for Drupal 7 looks like this:

At a first glance those numbers might seem a bit scary. However, right now focus is on the 36 critical issues, and especially the beta blockers. The other 485 pending bugs will get more attention as soon as the beta is out. Also, a lot of those bugs are very minor, could be something as simple as a space is missing somewhere, or lists are not sorted properly. Bugs that doesn't really prevent the functionality of Drupal, but needs to be fixed at some stage.

When Dries and Angie decide that Drupal 7 is stable enough, after a few betas, a Release Candidate (RC) will be announced. This is the final stage before the official release. By then all the remaining critical and major as well as the majority of normal bugs should have been fixed.

Generally speaking the RC stage should be the shortest phase. It is the litmus test to make sure there are no more bugs preventing a product to be used in an production environment.

When one, or a few, RC's have been released, tested and finally deemed to be solid enough then we will all celebrate the announcement of the official Drupal 7 release.

The above is what is preventing the official release of Drupal 7. As I'm sure you can imagine there are still a lot of work to be done before we get there. There are no shortcuts in this, especially for a project of Drupals magnitude and importance on the web. It has to take the time it takes. Remember, its all done by people who voluntary contribute their own time and experience.

You Can Help Too

You might think that you don't have enough knowledge about Drupal or development skills enough to be able to find bugs or even fix them. Nothing can be more wrong. There is room for everyone to help. In fact, the Drupal community is in need of more novices and end users to help chip in wherever they can. I have been in the IT industry since before IT was even a term and one thing I quickly learned was:

Don't let the developer write the user manual!

The developer knows the application inside and out, and that is also why they are not the best choice for writing a user manual, or even testing the software. They know the perfect way of using it and they simply has a tough time trying to think what someone who never seen it needs to be able to use it. For complex application, such as Drupal, it is impossible for the developers to think of every way it can be used.

This is why pre-release versions, alphas, betas and RCs, are released. Then more people can test it. They will test it from their point of view as well as in environments completely different to the developer environment. These testers will then feed back their experiences to the developers so it can be dealt with.

The Drupal community is a nice place. Yes, it takes a bit of time to understand how to file issue tickets if you have never done it before. The members of the community will help guide you in the beginning, telling what you do wrong and show you how to do it correct. The Getting Involved page is a great start to find out how you can contribute.

Below I have listed three areas related to Drupal 7 where you can get involved, as well as how. You also find links to pages where you can find more information.

I think you will quickly find that it is not only a lot of fun helping out, but that you also are going to learn a lot of useful stuff about everything around Drupal.

Drupal 7 Core

Obviously finding and fixing bugs in Drupal 7 Core is the most important thing right now. The quicker those bugs can be squashed, the sooner it will be released.

Help with Testing

This is easy. You simply only need to download release from the project page or from CVS, install it in your environment and play around with it. If you find any problems, go to the issue queue, search if anyone else already reported it. If its already found, read the discussion and see if there is anything you can add to it. If its not reported, open a new issue ticket and describe what you have found as detailed as possible. Best is if you can provide a step by step list of how to recreate the problem.

Existing Issues and Testing Patches

Another way is to simply look at the open issues and see if you can find any reported problems you can help with. You might have expertise in some areas that is valuable and can thus offer your assistance in solving the bugs.

When a developer is working on fixing a bug, they normally post a patch for that particular issue, asking others to test and review it to see if it solves the problem. You can download and install these patches and test them, then reporting back your findings.

Resources

Contributed Modules

Basically, helping with contributed modules is the same as helping with Drupal Core. Each module has its own project page on drupal.org, as well as their own issue queue. The main difference is that you need to keep an eye on what Drupal version the module requires. Especially before the official release. It might be that you need a dev version from a certain date for example. Some modules are also dependent on other modules to fully work, so you need to download and install those as well.

Besides that, use the same methods as I listed for Drupal Core.

Resources

Documentation

This is an area that often gets rather neglected in the open source world. One reason for this is that most open source projects are developer driven and writing documentation is "boring". There are many members of the Drupal community working very hard to make sure Drupal has very good documentation. They are doing a fantastic work, but there are lots of room for more people to chip in.

This is especially true when it comes to user documentation. There exists a lot already, but it is far from complete. The good part is that any member on drupal.org have permission to edit the documentation. You only need to click on the Edit tab and get going.

It is important to mention that in Drupal 7 there will be links to the handbooks on drupal.org. Therefore you need to balance what is available directly on in the help system of the Drupal 7 installation and the additional information on drupal.org.

A few days ago Ariane Khachatourians posted Drupal 7 Docs need your help! on drupal.org. It contains everything you need to know about how to help with this, as well as links to documentation guidelines etc.

Conclusion

Drupal 7 has come very far since it was first announced in the beginning of 2008. We are very close to a release now, but a lot of work is still needed before that happens.

I hope that these articles have given you a better idea of the current status and where it is heading. I also hope that especially this post will lead to that more people get involved in the project. If you do decide to give it a shot, I can virtually guarantee that you are in for a fun ride.

You will quickly learn a lot of useful stuff, make many new friends as well as feel you are being part of something very special - The Amazing Drupal Community!

And that ends my three part series about Drupal 7 for production sites. I hope you enjoyed reading it.

Posts in this series:

Tags: 
Drupal
Drupal 7
Open Source