Drupal blogs

From Dar
Jump to: navigation, search
187245847_edb0fa60b2_t.jpg This page is part of the drupal learning project | view pages

Personal blog of Dries Buyttaert

leader of the overall drupal project

Fostering inclusivity and diversity
Topic: 

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 ...

[?]
Drupal 6 support
Topic: 

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:

  1. Upgrade to Drupal 7 any time between now and 3 months after Drupal 8.0.0 is released.
  2. 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.
  3. 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.

[?]
About today
State of Drupal presentation (June 2014)

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).

[?]
A method for giving credit to organizations that contribute code to Open Source
Topic: 

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.

[?]
Acquia acquired TruCentric

We [?]

Acquia raises $50 million series F

We've got great news to share today; we are announcing that Acquia raised $50 million, the largest round of financing we [?]

Drupal 8 Q&A session at DrupalCon Austin

Do you have questions about the upcoming Drupal 8 release (or Drupal 9 and beyond)? On Thursday, June 5 at DrupalCon Austin, I'll be moderating a question-and-answer core conversation with a panel of key Drupal 8 contributors. Questions are submitted in advance online, and anyone can submit a question. I will curate the submissions to ask the panel the most interesting and relevant questions.

This is a rare opportunity for the community to communicate directly with the trailblazers who are shaping Drupal 8 into the best release of Drupal yet. Help us make the most of of it -- submit your questions now!

[?]
The investment case for employing a Drupal core contributor

I've long been convinced that every well-run Drupal agency of 30 people or more can afford to hire a Drupal core contributor and let him/her work on Drupal core pretty much full-time. A healthy Drupal agency with 30 people should be able to do $5MM in revenue at a 15% net profit margin #1. This means they have $750k in profits that can be invested in growth, saved as reserves, or distributed among the owners.

There are many ways you can invest in growth. I'm here to argue that hiring a Drupal core contributor can be a great investment, that many Drupal agencies can afford it, and that employing a Drupal core contributor shouldn't just be looked at as a cost.

In fact, Chapter Three just announced that they hired Alex Pott, a Drupal 8 core maintainer, to work full-time on Drupal core. I couldn't be more thrilled. Great for Alex, great for Drupal, and great for Chapter Three! And a good reason to actually write down some of my thoughts.

The value of having a Drupal core contributor on staff

When Drupal 8 launches it will bring with it many big changes. Having someone within your company with first-hand knowledge of these changes is invaluable on a number of fronts. He or she can help train or support your technical staff on the changes coming down the pipe, can help your sales team answer customer questions, and can help your marketing team with blog posts and presentations to establish you as a thought-leader on Drupal. I believe these things take less than 20% of a Drupal core contributor's time, which leaves more than 80% of time to contribute to Drupal.

But perhaps most importantly, it is a crucial contribution that helps ensure the future of the Drupal project itself and help us all avoid falling into the tragedy of the commons. While some core contributors have some amount of funding [?]

Acquia drops non-compete clauses

In a world where innovation is only accelerating, shackling employees with non-competes doesn't make sense anymore. At Acquia, we believe that innovation is about openness and collaboration, and that working together is based on trust and loyalty, something that was born out of our Open Source background. It's been a long time coming but we decided to kill our non-competes. It is the right thing to do. Here is what we just sent to all Acquia employees:

 From: Tom Erickson <tom@acquia.com> To: Everybody at Acquia Date: Friday, May 2, 2014  Acquians,  We have an amazing team, it's the thing I am personally proudest about.   When asked by others what's the best thing about our company, I don't hesitate to answer "our team".  There are many things to value in each of you, from your commitment,  your integrity and certainly your passion!  The goal that Dries and I have always set was to have a company where everyone is challenged, has the opportunity to grow and has some fun along the way.  Most of the time we're successful at that as a company,  though sometimes we fail.  Yet even when we fail, we want everyone to  continue to do the right thing and sustain mutual respect.  To this end, the exec team has decided to eliminate non-competes from  our employment agreements.   We believe its the right thing for our  team members, for the company and for the industry.  There are many  reasons why companies have used non-competes in the past, but we  believe that times have changed and individuals today value the  companies who value them.  This may seem contradictory .. "value me,  but let me go to a competitor" .. but we believe that a company who  respects our team members in this way will actually be a better magnet  for talent.  While we are getting rid of non-competes, we are not eliminating other terms, notably the non-disclosure.  So while we do not want to restrict  free movement of talent, it's important that company confidential  information remains just that, confidential.    We do not plan to change existing employment agreements, as that would  be an administrative burden, and we have many other issues to deal with. This email should suffice as an assurance that existing non competes  below the executive leadership level will not be enforced.    All new hires, with certain exceptions at the executive level, will not have non-competes.    Viva Acquia! Tom
[?]