myDrupal

I was the first woman at any DrupalCON, the only woman in Antwerp. Until the brouhaha over the keynote, I never really thought about why I went there in the first place. But the decision to travel there was triggered by a tiny and important event, so I'd like to share it.

I had been communicating back and forth with Matt Westgate about some e-commerce functionality. At the end of one of his emails, he tacked on the following:

PS - You headed to Belgium?

This question wasn't a part of an outreach initiative to involve women in open source. I doubt he questioned that my interest might be affected by my gender. It was simply, "we're having an interesting conversation that would be even easier to have in person". Before I read that email, the thought of traveling to DrupalCON hadn't crossed my mind. But my response to that simple question was to make it happen! And thus my life was changed.

But five years later in San Francisco, when the number of women in attendance had risen from 1 to 300, I was settling into a BoF session when I was presented with another innocuous question:

This is a technical BoF. Are you sure this is where you intended to be?

This question was not intentionally harmful. It was an offer of help, in a tone of "hey, do you need some help finding your way to a session you might enjoy more?". But this "help" was based on the unconfirmed likelihood that I might not belong in a technical session. If I was new, I might have doubted my own aptitude and diminished my participation.

This post is not about lambasting the BoF guy or calling out the similar encounters we encounter every day, such as asking if I'm on the documentation team, a designer, or just there with my partner. This happens regularly and quite cordially, usually perpetrated by someone who you wouldn't call 'sexist'. But good or bad, tiny exchanges make up our community as a whole, and have a much broader impact. What if Matt, without any derogatory judgment, questioned my interest in showing up in Antwerp? What if he hadn't bothered to ask? Five years later, would I be contributing to Drupal, running a company that employs other Drupal contributors, and helping to support the local Drupal community?

More importantly, what if more people reach out to others in similar ways? How many others would there be out there doing more good for Drupal? Setting aside the topic of what is/isn't "offensive", how do we focus on being more inspirational, and asking questions instead of making assumptions?

Drupalchix

geekia.es is a cretive lab based on Drupal. The deal is to get a clear, profesional but casual feel.

As our community grows, it is imperative that we preserve the things that got us here; namely, keeping Drupal a fun, welcoming, challenging, and fair place to play. The new Drupal Code of Conduct (DCOC) states our shared ideals with respect to conduct. Think of this as coding standards for people. It is an expression of our ideals, not a rulebook. It is a way to communicate our existing values to the entire community.

Our friends at Ubuntu have blazed a brilliant trail in this area. They use Drupal as their CMS, and in turn we have embraced their Code of Conduct. This code of conduct is essentially identical to that used by Ubuntu, except that the name of the project has been changed, and the conflict resolution process has been removed since we don't have one.

The DCOC has been under discussion for several months on groups.drupal.org and discussed further at Drupalcon Conpenhagen. Folks who are interested in talking more about the DCOC should do so in the Drupal.org Policies group.

The short version:

1. Be considerate
2. Be respectful
3. When we disagree, we consult others.
4. When we are unsure, we ask for help.
5. Step down considerately.

read more

We have recently launched our new hosting and digital agency website and made the migration from Expression to Drupal. The Drupal powers all our content managed areas and email subscriptions.

This past March, I decided it was time to put my skills as a Drupal developer to use and launch a new online business. I knew early on that I wanted this business to be product-based, and after several weeks of playing with different ideas, I settled on selling premium Photoshop layer styles. It was the perfect opportunity to combine my love of photography and Photoshop with my passion for web development and Drupal.

Several months of product development later, StyleWorks was born. The site runs on Drupal 6, and integrates with FastSpring for e-commerce capabilities.

Designing the site: To Zen or not to Zen?

After iterating through several hundred designs in Photoshop, I finally had the look I wanted to go with, and it was time to make it come alive in Drupal. But first, a key decision had to be made: Start from scratch, or go with Zen?

read more

Web-site for Théâtre Forum Meyrin.

In 2009 Appnovation Technologies was asked to design and develop a Drupal based community and e-commerce website called Cargoh. The driving idea behind the site is to create a “social marketplace” for independent artists from all over the world to be able to showcase and sell their products and services. It features community tools such as forums, an internal messaging system and events section.

Cargoh.com was founded by Paul and Cariann Burger when they noticed the lack of avenues for independent artists, designers and musicians to get their work to the world. They realized that some of the most talented people in the world were making them coffee in the morning at the local coffee shop. They set out to change that by creating a super accessible, highly affordable and unbelievably feature rich venue for artists, designers and musicians to sell the things they create. Above that, they wanted to create the world's best online shopping mall for all the uniquely independent products in the world. So from those two missions, Cargoh.com was born. The world's most exciting social marketplace for independent creatives!

read more

Founded in 1991, The Cara Program is a Chicago-based non-profit that empowers men and women affected by homelessness and poverty with the skills, confidence and resources to secure and sustain quality jobs and achieve long-term success. Since their founding, they have placed more than 2,500 individuals into full-time, rewarding positions with leading Chicago area companies such as ABM Lakeside, The Hilton Hotels, JP Morgan Chase, Sodexho, and more.

The Cara Program sought a redesign of their static website, one that engaged visitors by quickly delivering key information that was clear and concise, and could be easily maintained by Cara staff. Being a non-profit website, they also needed a way to accept donations, recruit volunteers, allow visitors to join their mailing list, and recruit sponsors and employment partners. In addition to being able to simply accept donations, they wanted to eventually “empower” donors to use social media and/or other outlets to spread the word, champion their cause and help others donate or otherwise support. The ability to share some content also needed to be a feature on The Cara Program "child" program websites: Clean Slate, Quad Communities and Career Pathways.

Duo Consulting was chosen to implement their goals and Drupal was the platform chosen.

read more

Start:  2010-10-02 08:00 - 09:00 UTC Drupalcamp or Regional Summit Organizers:  Mediacurrent

Drupalcamp Atlanta 2010 (www.drupalcampatlanta.com) is now open for registration, and will be held on Saturday, October 2nd from 8am – 5pm at the Georgia Tech Research Institute. Our mission and purpose is twofold: (1.) we want to educate people about Drupal and (2.) further evangelize Drupal within our geographic region. The 2nd annual Drupalcamp Atlanta is an attendee driven, completely volunteer initiative modeled after the open, participatory nature of barcamps. We are offering four tracks this year: (1.) Drupal for Beginners (2.) Design, Theming, and Usability (3.) Development and Performance and (4.) Drupal for Business and Services. If you are new to Drupal we definitely want you to come – in fact, during registration we have carved out space and time for a “Drupal Installfest” before the sessions start.

This year’s venue at Georgia Tech will be spectacular. The main auditorium offers stadium-style keynote seating, power outlets in every other seat, and a reliable wifi set-up. The schedule will involve high-quality breakout sessions, an attention-grabbing keynote from a to-be-determined speaker, a coder’s lounge, sponsor booths, and an executive boardroom for special Birds of Feather (BoF) type gatherings. Want more? OK, when we are done we are going to have a party from 6-9pm at a nearby, soon-to-be announced restaurant where the networking and good times will be sure to follow.

Amazingly, this year’s event will cost a modest $25 for an all-day conference badge and will include breakfast, lunch, and snacks. For an extra $25 ($50 total), you can become an individual sponsor and we will provide you with an official t-shirt and recognition on the DCA website. Many thanks to the 13+ organizations who have already signed on to become a sponsor – sponsorship opportunities are still available.

How can you help? We need more volunteers, particularly those who would be willing to loan us video equipment, take pictures, or shoot footage of sessions– contact us and we will get in touch. Next, we need presenters to submit sessions. After being inspired by kick-ass Drupalcamp sites like Los Angeles and Colorado we added a voting component and commenting feature this year to allow potential speakers more attendee input leading up to the camp. The ability to submit sessions is now open and will close on September 10th at MidnightEST. Let me state the obvious, but the earlier you get your session submitted the more opportunity for votes and feedback.

Finally, here is the best piece of advice I can give you – REGISTER NOW. Due to venue constraints, we are capping attendance at 225. Last year’s event sold-out two months in advance, so do not risk getting shut-out.

Follow Drupalcamp Atlanta on Twitter @Drupalcamp_ATL

www.drupalcampatlanta.com

triDUG

One of the big goals of the drupal.org redesign is to make it easier for end users to find the right modules for the site they're trying to build. With over 5,000 contributed modules, many of them providing similar functionality, it can be extremely difficult to choose. One method is to try to assess the "health" of the module, by how actively it's maintained, used, supported, etc.

One approach to gauging health is posted at Project ratings and reviews for drupal.org redesign. While that proposal deals with subjective factors, this post addresses objective facts about a module that can be computed and displayed for all projects hosted on drupal.org. While no single metric can tell you what module to use, and some knowledge will be required to make the best use of this data, it's important to make these statistics more readily available on drupal.org to empower users to make better decisions.

The redesign prototype for project pages includes the introduction of a sparkline showing the "Activity" for each project.

The details of this activity chart weren't specified at a technical level during the design phase, but the spirit of the design is that they wanted more ways to visualize the health of a project. As we're implementing the redesign, we've been empowered to provide as many charts containing specific data we think will best help end users make sense of what's going on with a project. Read on for our specific proposal, including what metrics to compute, and some ideas on how those are going to be visualized on the new drupal.org

Specific metrics

There are literally dozens and dozens of metrics that could be captured and displayed. We've already got support for the usage of any given project and we're working on support for download statistics. Beyond those, we believe the following are important to assess the overall health of a project at a glance:

1. Issue activity: Each project category (bug, feature request, etc.) -- number open vs. number fixed/closed
2. Number of issue reporters (unique users filing new issues in a defined time period)
3. Number of issue participants (unique users filing issues or comments in defined time period)
4. Total number of issue comments posted over a week (ideally with a separate total for the number of comments by any of the project maintainers, both of which can be graphed on the same sparkling).
5. Release activity: Number of releases in each time period

We're proposing to normalize all metrics to a weekly granularity. This would both simplify the storage (so we're not trying to store daily metrics) and the UI (since it'd be best if all the charts used the same granularity to make it easy to compare them).

Additionally, the following metrics could be useful, but we might not have time to implement them for the initial launch of the redesign:

1. Commit activity (This would be great, but it's not worth our time to add this for CVS with the Git migration imminent).
   • Number of lines added/removed
   • Number of commits
2. Total number of tests and percentage of tests that pass
3. Total lines of code vs. lines of comment
4. Average length of time that issues are open
5. Number of unique users
   • submitting patches
   • reviewing patches

We're trying to strike a balance between what's relatively easy and sane to compute, implement and display visually, and things that will help users find the best project for their particular needs. Given that, if you have suggestions for other metrics we should be considering, please comment below!

Enter the project_metrics module

We looked at a lot of Drupal charting modules (see below), but basically none of them handle the storage for you. So, no matter how we end up displaying this data, we need somewhere to compute and store it. Enter the project_metrics module.

This would be a new sub-module included directly in the Project project. While the project_usage module is really only relevant to sites that are using Project to manage releases of Drupal code to track update_status usage, the project_metrics module could be useful for just about anyone running the Project suite. It would be responsible for computing the metrics and storing them.

To compute, the idea is we'd write a series of drush commands that would be run periodically to do all the heavy lifting to compute the right statistics for a given week. These commands would insert records into the project_metrics module's DB tables. Then, project_metrics would provide various ways to access and display the data (see below).

The basic architecture of the module is that it would invoke a hook to allow other modules to advertise what metrics they want to provide. The project_metrics module would then be responsible for invoking the appropriate functions in the other modules at the right frequency and storing the results. So, project_metrics itself wouldn't know how to query the issue database tables looking for statistics. That'd still be the responsibility of the project_issue module. However, project_issue wouldn't have to worry about invoking itself via cron, wouldn't have to manage its own tables to store the historical data, etc.

Front-end display

So how would all this data be visible on drupal.org? The key metrics would be exposed via sparklines on the project page itself. Depending on how many metrics we end up with, we might need to add a tab off project pages (or use JS to show/hide the full list of metrics) so that it's possible to drill down and find as many statistics as we provide, without overwhelming the user with all of that data directly on the default project pages. My vision is that there's an easy way to see 5 - 10 sparklines, each with datapoints at 1 week granularity, all vertically stacked so the weeks line up. That way, you can see how the different metrics correlate. So long as the scale of the horizontal axis is the same on all graphs (so they line up and are easy to compare), we can use a different scale for the vertical axis for each sparkline so that they all make the most visual sense (e.g. the number of releases in a week is probably going to be 0-4 most of the time, whereas the number of issue comments or lines of code added/removed could be in the hundreds or thousands). With the charts stacked so the weeks line up, you could easily see for example that one week the "number of lines of code added/removed" sparkline goes nuts, and the "number of open bugs" chart started climbing soon thereafter. ;)

There are some metrics and statistics specifically about the issue queues that are already on drupal.org, they're just mostly hidden. For example, you can view statistics about the Drupal core issue queue. This page will probably get some much-needed attention (it hasn't been touched in years). Although none of the UI parts of this proposal are set in stone, it's likely that we'll update these per-project issue statistics pages to include more of the issue-related metrics discussed above. The idea is that we'd put the current week's raw data in the tables near the top of the page, and then provide sparklines below to see how those values have changed over the weeks of the last year.

Additionally, we're going to expose some of these metrics to Solr to make it possible to filter and sort projects by various metrics. We've already done this with the project usage data (for example, this is the default sort order when you browse module projects on drupal.org). So, in addition to being able to sort by "Most installed" (and hopefully soon, "Most downloaded"), you might also be able to sort by "Most active issue queue", "Smallest % of open bugs", "Most commit activity", etc.

However, when it comes to visualizing the data that the project_metrics module would be providing, we've investigated a few possible ways to generate the necessary charts:

Sparkline-aware views display plugin

We could expose all of the project_metrics data to views, create views for whatever we care about, and write a Views display plugin that knows how to render our results as a sparkline. This could potentially be done as part of the Views charts project, or as its own new "Views sparkline" contribution. Either way, we'd hope to make use of the Sparkline module. The Views display plugin would simply be glue to take the data from the results of the query that Views ran and format that data in a way that the Sparkline module expects to be able to generate the sparkline itself.

Charts API

We could potentially use the Charts API to handle our charting needs. We'd still probably drive the queries via Views and have a display plugin to render the results via the Charts API. So, this is more an alternative to the Sparkline module itself -- either way we'd probably be exporting the project_metrics data to Views and writing a display plugin.

Quant

We looked at the Quant module, but it doesn't really seem like it gets us very far. It can do really complicated queries to try to figure out the historical data for you, but that's going to probably kill the d.o database server. It doesn't do any storage for you. And, we'd have to write some code to expose our data to Quant. At that point, we might as well just expose it to Views since that seems a lot more flexible and powerful.

Implementation roadmap

From now until around August 20th, we're just going to gather feedback on this proposal. To prevent the discussion from getting fragmented, please add comments directly on this post.

Starting around August 23rd, we're going to begin implementing the project_metrics module, and any changes to the rest of the Project suite, to make it possible to compute all these statistics. We expect all the backend work to take approximately two weeks.

Starting around September 7th, we're going to evaluate the front-end options and pick one to roll out on drupal.org. We're aiming to get these metrics visible on project pages and in the ApacheSolr index on the live drupal.org independent of the launch of the redesign theme (which is called "bluecheese"), unless it involves significant work in the existing drupal.org theme ("bluebeach").

Background reading

Interested readers can check out the following threads for more on this juicy topic:

• Project Quality Metrics on Drupal.org (meta document)
• Automate gathering of quality metrics
• Project module's hidden project metrics

Drupal.org redesign implementers

It's time for another update from DrupalCon Copenhagen! This time around we have updated information on the core developer summit, the unconference, and the code sprint.

Official Program

First of all, we are happy to announce that the final version of the program is now available on the site. The few remaining slots in the schedule will be used for sponsor sessions and lightning talks. We'll try to keep schedule changes to a minimum, but if we do have to shuffle a few sessions around, this is the page to watch. Also, we'll make the entire program available as a PDF if you would rather keep it on your laptop or print a copy to keep in your pocket during the conference.

Now that the program has been finished, you can start planning your DrupalCon Copenhagen. Go to the session schedule and add all your favorite sessions to your personal schedule. You can see a list of your chosen sessions by going to your user profile and clicking the "My schedule" link.

Core Developer Summit

If you're in Copenhagen on Sunday, August 22nd, and interested in helping improve Drupal core, you should participate in the Core Developer Summit. The summit will provide opportunities both for people to discuss changes to Drupal code and processes as well as people interested to move Drupal 7 closer to release. The summit will start wit three shorts sessions by Dries Buytaert, Sam Boyer, and Jen Simmons. After the kick-off sessions, the summit will break up into two groups, with plenty of space to be fruitful and get stuff done. All ideas are welcome!

read more

It's time for another update from DrupalCon Copenhagen! This time around we have updated information on the core developer summit, the unconference, and the code sprint.

Official Program

First of all, we are happy to announce that the final version of the program is now available on the site. The few remaining slots in the schedule will be used for sponsor sessions and lightning talks. We'll try to keep schedule changes to a minimum, but if we do have to shuffle a few sessions around, this is the page to watch. Also, we'll make the entire program available as a PDF if you would rather keep it on your laptop or print a copy to keep in your pocket during the conference.

Now that the program has been finished, you can start planning your DrupalCon Copenhagen. Go to the session schedule and add all your favorite sessions to your personal schedule. You can see a list of your chosen sessions by going to your user profile and clicking the "My schedule" link.

Core Developer Summit

If you're in Copenhagen on Sunday, August 22nd, and interested in helping improve Drupal core, you should participate in the Core Developer Summit. The summit will provide opportunities both for people to discuss changes to Drupal code and processes as well as people interested to move Drupal 7 closer to release. The summit will start wit three shorts sessions by Dries Buytaert, Sam Boyer, and Jen Simmons. After the kick-off sessions, the summit will break up into two groups, with plenty of space to be fruitful and get stuff done. All ideas are welcome!

read more

A nice and clean website for Zeeuws Klimaatfonds. Zeeuws Klimaatfonds is an organisation for voluntary climate compensation in the local area Zeeland in The Netherlands. The site is in Dutch.

One Person Shop - Interactive Design Bureau.

Download Drupal 6.18
Download Drupal 6.19
Download Drupal 5.23

Drupal 6.18 and 5.23, maintenance releases which fix security vulnerabilities are now available for download.

Drupal 6.19 also fixes other small issues reported through the bug tracking system.

Upgrading your existing Drupal 5 and 6 sites is strongly recommended. There are no new features in these releases. For more information about the Drupal 6.x release series, consult the Drupal 6.0 release announcement, more information on the 5.x releases can be found in the Drupal 5.0 release announcement. Drupal 5 will no longer be maintained when Drupal 7 is released. Upgrading to Drupal 6 is recommended.

read more

Download Drupal 6.19
Download Drupal 5.23

Drupal 6.18 and 5.23, maintenance releases which fix security vulnerabilities are now available for download.

Drupal 6.19 also fixes other small issues reported through the bug tracking system.

Upgrading your existing Drupal 5 and 6 sites is strongly recommended. There are no new features in these releases. For more information about the Drupal 6.x release series, consult the Drupal 6.0 release announcement, more information on the 5.x releases can be found in the Drupal 5.0 release announcement. Drupal 5 will no longer be maintained when Drupal 7 is released. Upgrading to Drupal 6 is recommended.

read more

This post is part of a series to inform the Drupal community about the drupal.org redesign project, and the work the Drupal Association is funding to help get the redesign completed. If you would like to contribute to the redesign as a volunteer, see the community initiatives redesign page. If you'd like to contribute to the redesign financially, see the Drupal Association memberships and donations pages.

read more

Ice Scan is a product search engine for consumer electronics, computer hardware and software, telephony, mobile phones, household appliances, and much more...

Ice Scan's search technology is based on Drupal's Apache Solr Search Integration,
http://drupal.org/project/apachesolr

Ice Scan uses the domain and i18n modules to build a fully multi-domain, multi-site and multi-lingual system. 12 languages, 11 domains, 11 Solr databases - all from 1 Drupal core using 1 MySQL database.

Also part of the series are:

http://ca.icescan.com - Canada
http://www.icescan.co.uk - United Kingdom

read more

With Drupal 7 down to 30 critical bugs, and Drupalcon Copenhagen just around the corner, it's only a matter of time before Drupal 7.0 ships. We want to make sure our Drupal 7 documentation is in great shape for this fantastic new release, and the Documentation Team could really use YOUR help getting there!

read more

PulpMX.com was launched in early 2009 as a place for well-known motocross columnist Steve Matthes to post his musings about the sport and its history. Originally conceived of as a modest site, it was built in early 2009 using a stock theme with a handful of custom images, the FCKeditor and IMCE modules to provide a built-in visual editor, and little else. Over time it had grown organically as needs developed: CCK, Filefield, and SWF Tools for posting audio interviews in a built-in player, for example. In early 2010 PulpMX also took on discussion forums from a site that was no longer able to host them, so an existing phpBB installation was also imported.

The site was developing a growing following and it was becoming obvious that it needed an overhaul to better reflect the character of the site, and provide more cohesive and initiative navigation among the quickly expanding areas of the site. Says Steve:

Originally I had gotten Tooth and Nail to design me a basic site for blogs and photos, what they gave me was way better than I had thought I needed. The traffic and the new media things that I was doing (podcasts, slide shows and a live internet show) demanded that I get something new and fresh. I was now big-time I suppose.

read more