The past few weeks, I've been thinking over and over again trying to rationalize how to best foster a culture of inclusivity and diversity. This in the context of creating a productive work climate of trust and respect.
I think it is fair to say we all want other people to feel welcome and respected. Where that gets difficult is that feeling welcome and respected means something different to different people. What seems harmless to you could be hurtful to another. For example, some people tend to be more concerned about the use of crude or sexual language than others. It's a complex issue based on a range of factors including gender, race, age, geographical location and more. There is also a lot of academic research about the fact that derogatory and vulgar language or sexually graphic behavior creates a hostile environment. These two facts combined, makes it a popular topic in the context of diversity and inclusion.
However it is not just a popular topic, it is also a very difficult topic. Why do we feel defensive and argumentative when confronted with a value and belief system different from our own? It is one thing to challenge someone's take on, say, a country's healthcare system, it is another thing to challenge someone's beliefs. Challenge someone's beliefs, and you challenge their sense of self.
Given all this, is it possible to be inclusive of everyone? For example, can we be inclusive of those who are easily put off by sexually graphic or vulgar language and at the same time be inclusive of those who often use crude or sexual language? Does supporting one group of people mean turning away others? I hope not, but I'm not sure. Can we find a balance when we have conflicting behaviors? Sometimes we need to change behavior (eg. tone down or refrain from using bad language), and other times we need to understand when no offense was intended, and try to accept and accommodate cultural differences.
Answering these questions to define our culture is very difficult. It is even harder to put them into written rules. I strongly believe that being inclusive is a mindset first. It is about wanting to be a good person to all other people. Once you have it in your mind that you want to make others feel respected and comfortable around you, you'll find that you'll be looking for ways to do so. The key is to be appreciative of our differences. If you show respect and sincerity and remain open to hearing differing opinions, we will automatically become more aware of how our actions affect people different from ourselves. We'll automatically become more inclusive and more diverse.
By the same token, being appreciative of how we are different also means you should be willing to give the benefit of the doubt in case you are offended. It's only through fostering an environment where it is safe to make mistakes and learn from each other that we can achieve diversity and inclusiveness in our community.
Last but not least, it also presents a tremendous opportunity to learn about new cultures. I hope to learn from people who are different than me and talk honestly about our differences. If you are one of these people, I hope to ask you questions respectfully to learn more about how your values differ, and would love to find out how you want to be treated.
I'll continue to think about how to best foster a culture of inclusivity and diversity, but I wanted to stop and listen first ...
The policy of the Drupal community is to support only the current and previous stable versions of Drupal. If we maintain that policy, Drupal 6 support would be dropped the day that Drupal 8 is released. We'd only support Drupal 8 and Drupal 7.
We're changing that policy slightly as there are still around 200K known Drupal 6 sites in the wild, and we want to ensure that sites that wish to move from Drupal 6 to Drupal 8 have a supported window within which to upgrade.
The short version is that Drupal 6 core and modules will transition to unsupported status three months after Drupal 8 is released. A three month extension is not a lot, but continuing to support Drupal 6 is difficult for many reasons, including lack of automated test coverage. This gives Drupal 6 users a few options:
- Upgrade to Drupal 7 any time between now and 3 months after Drupal 8.0.0 is released.
- Upgrade to Drupal 8 after it is released, but before Drupal 6 is not supported anymore. There's already a Drupal 6 to Drupal 8 migration path in core which can be used for testing. Keep in mind though that if your site relies on contributed and custom modules, you may need to port the code and write the migration paths yourself if they're not done by the community in time for Drupal 8's release.
- Find an organization that will provide extended support for Drupal 6. We hope that organizations that rely on Drupal 6 will step up to help maintain it after community support winds down. The Drupal Security Team will provide a method for companies or individuals to work together in the private security issue queue to continue developing updates, and will provide a reasonable amount of time for companies to provide patches to Drupal 6 security issues that also affect Drupal 7 or Drupal 8.
You can read the details on https://drupal.org/node/2288521.
Today Morten Birch Heide-Jørgensen stepped down from his role on the Drupal Association's Board of Directors. The Drupal Association's Board of Directors supports Morten’s decision. The Drupal Association and the Drupal community value inclusivity and diversity, and our leadership must demonstrate those values as well.
We want to thank Morten for his service; he came to the board with a mission to foster improved transparency and communication. He helped both the board and staff embrace those principles in a way that will carry into the future.
Today’s development underscores the need for a broader discussion that we need to have about inclusivity and diversity. Creating and maintaining the right culture and environment is vital to Drupal's success. Therefore, we have asked the Community Working Group to define a process to help our community address these issues and identify positive, proactive, and concrete steps we can take to ensure that everyone feels welcome in Drupal.
Morten is vacating a community elected seat. The Board of Directors will discuss how and when to fill this vacancy at the next board meeting.
I gave my traditional State of Drupal presentation this week at DrupalCon Austin. You can watch the recording of my keynote if you are interested in learning about my vision for the future of the web, the challenges and opportunities ahead of us, how Drupal fits into that. In good tradition, you can also download a copy of my slides (PDF, 120 MB).
If we want to encourage more organizations to contribute to Drupal and hire core developers, we should start to give them credit for their contributions. I'd love to see us maintain a page on Drupal.org that shows which companies contribute to Drupal and in what capacity. This credit provides these organizations a tangible benefit in recruiting developers, demonstrating their expertise, and more. Credit is a powerful motivator for individuals, but also for businesses. It is a form of trust currency.
It is great that we give individual contributors credit for their contributions, and we should continue to do so. However, I'd like to extend that to organizations, both to the Drupal agencies as well as their customers. Mapping out how contributions get funded can be great for individuals, customers and digital agencies.
A great way to start doing this, is to adopt a new format for Git commit messages. I'd like to propose the following format:
$ git commit -am "Issue #n by INDIVIDUAL@AGENCY*CUSTOMER: message."
We prefix agencies with @ and customers with *. I believe this provides us the necessary flexibility. We could choose to store this in Git Notes, if we prefer, but that is not the main point.
Contributed a feature as an individual consultant directly for a customer or end-user:
$ git commit -am "Issue #n by INDIVIDUAL*CUSTOMER: message."
Contributed something in your spare time and don't want to give credit to your employer:
$ git commit -am "Issue #n by INDIVIDUAL: message."
Let's put it all together with a real example. Imagine Sam, Megan and Tim collaborated on fixing a performance bug. Sam helped in the "20% time" provided by her employer Acquia, Megan helped in her spare time after work, and Tim worked on this on behalf of his employer, Pfizer, who is affected by this bug. Ideally, the commit message would look like this:
$ git commit -am "Issue #42 by Sam@Acquia, Megan, Tim*Pfizer: fixed performance bug."
The great thing about this approach is that we can adopt it today and worry about analyzing the data later. It also works regardless of where your Drupal code is hosted (Drupal.org, GitHub, etc) or what your source code management system of choice is (Git, SVN, etc). In fact, I believe all Open Source projects would benefit from this level of transparency and that giving credit directly into the commit message makes it very transferable.
If adopted, we'll want to build tools to help us create these commit messages (i.e. have contributors provide proper attribution in a new project issue field so the maintainers/committers don't have to manually create it).
With this level of transparency, we can start to study how our ecosystem actually works; we can see which companies contribute back code and how much, we can see how much of the Drupal project is volunteer driven, we can better identify potential conflicts of interest, and more. But most of all, we can provide credit where credit is due and provide meaningful incentives for organizations to contribute back to Drupal. I believe this could provide a really important step in making Drupal core development more scalable.
I'd love to hear your thoughts about us giving organizations credit.
Update: this was rolled out on drupal.org in 2015. Instead of providing the credit in a Git commit message we built a user interface for it.