Web Design and Development

The Process for Evolving Community Governance

Drupal - Fri, 05/05/2017 - 11:59
Discover > Plan > Build > Iterate

There comes a time when we must all recognize that what got us here won't get us there. Now is that time for Drupal. The governance models that were put in place to support the needs of the community years ago are no longer working as well as they should. The Drupal community has reached a level of maturity that requires greater clarity, integrity, and resilience.

An effort is underway to evolve Drupal’s community governance. The Drupal community is in the driver’s seat. The Drupal Association is helping navigate and get the community where it wants to go by providing the structure, support, and resources that are desperately needed to make progress. I, Whitney Hess, have been engaged to be a neutral facilitator of this process.

We are proposing a multi-phase approach to redesign Drupal’s community governance models, management, and decision-making practices: Discover > Plan > Build > Iterate. In this first phase, our goal is to gain a deeper understanding of the needs of the Drupal community. We are conducting this research through a variety of methods: one-on-one interviews with select individuals; mediated group discussions; surveys and feedback forms.

We held seven hour-long Community Discussions over three days of DrupalCon. There were 6-10 participants per session. Though every session had its own energy and topics varied, all discussions were fruitful and impactful. Many participants said they left feeling better than when they arrived.

While there was some discussion about recent events in the sessions, the focus quickly shifted to brainstorming ideas for how to improve Drupal’s community governance. As mediator, it is my role to help people articulate their needs, and to support the community in devising strategies to better get those needs met. Please read the meeting summaries if you would like to get a sense of what was discussed.

There are currently seven online sessions scheduled over the next two weeks at a variety of times for the global community to participate in these facilitated discussions, and more will be scheduled if needed. If you want your voice heard, I strongly encourage you to join us. If you have questions or concerns about the sessions, you’re welcome to contact me directly at whitney@whitneyhess.com.

Once these sessions are completed, we will be conducting a short survey and other types of feedback forms to have the widest possible reach. We want to ensure that people have a variety of ways to constructively contribute to making Drupal the best it can be. We expect to launch these in late-May.

At the conclusion of the Discovery phase, we will move into Planning. We are at the earliest stages of conceiving a Governance Summit over 1-2 days in June to take all of the learnings from Discovery, and craft a strategy for specifically how to change Drupal’s community management and governance. As of today, we do not yet have dates, location, or participant information. We are waiting to see what comes out of Discovery before we devise any framework for how this can be achieved effectively and equitably. Again, the Drupal Association’s role here is to be a support, and to create space for the community to decide how it wants its governance to change.

I have very clearly heard a need for greater transparency into this process and how decisions are being made. I take that responsibility seriously, and will continue to share our progress along the way. Next up, please look out for a summary of our Discovery findings, to be shared in late-May/early-June.

With gratitude,

Whitney

Supporting the next evolution of Drupal's Community Governance

Drupal - Thu, 04/20/2017 - 20:19

TL;DR: Both the community and Dries Buytaert, Project Lead, see a need to evolve Drupal community governance. The Drupal Association can help in a support role. We will start by hosting mediated community discussions so everyone around the world can participate, be heard and understood, and share their ideas. Creating a new governance model will take many months and will require an agile approach as we all feel our way through the proper steps. The Drupal Association will continue to find ways to support this process as we all move through it together.

-------------

Over the last several weeks, the Drupal Association has been in listening mode — and we still are. We’re hearing community members say they need clarity and understanding, and that our community governance needs to change. As we process what we’re hearing, we want to find the best way to help the community address the issues being raised, within the boundaries of the Drupal Association charter.

The Drupal Association’s mission is to unite the global community to help build and promote the software. We do that in two very specific ways: DrupalCon and Drupal.org. We’re determining how best to meet the community’s needs as it relates to these two key community homes. In the near future, I will publish blogs with ideas on how we might address the various needs we are hearing.

Evolving Community Governance

There is one need that we hear loud and clear that we can address today: The community needs support to evolve community governance structures and processes. Both the community at large, and Dries Buytaert, Project Lead, have expressed this need, and we are glad to see this alignment.  

It’s important to note that the Drupal Association has a very limited role in community governance. Our only role in governance stems directly from our charter to manage DrupalCon and Drupal.org.

It’s not within our charter to oversee community governance or drive its evolution. The last thing the Drupal Association wants is to step outside of our charter or accidentally take away the community’s agency in self-organizing to create the new community governance model. However, we do want to facilitate forward movement. And so, we can take a support role.

We hear that many in the community want to come together to talk. We can support this by providing a meeting place (both in person and online), and a mediator for community discussions.

We have asked Whitney Hess, a coach who has worked with the Drupal community before, to facilitate and mediate community discussions, where people can come together to talk about current community issues and explore ideas for improved governance. These discussions will start at DrupalCon Baltimore and continue in a series of online meetings, scheduled at different times so members around the world can participate. [see more details below]

To provide transparency for those who cannot attend the discussion sessions, we will post meeting minutes and summaries from each community discussion here: https://drupal.org/community/discussions.

As facilitator of these community discussions, Whitney Hess will provide a summary to give us a broad perspective on the “voice of the community.” We hope these conversations will ground the community as it begins architecting its new governance model.

Once we have had these discussions we can decide together on the appropriate next steps, and how the Association can help the community continue to move forward, together.

Join Community Discussions

We hope you'll join the conversation as these discussions begin. Again, our overarching aim is to support the community so it can be healthy and continue to thrive. We believe that open conversation is essential to the wellbeing of any community and we look forward to hosting Community Discussions mediated by Whitney Hess. Please join fellow community members to talk through recent community issues and to be part of co-creating Drupal’s new governance model.

Here are the discussions you can join. Please note the ground rules below:

At DrupalCon Baltimore         

Location: Pratt Street Show Office

Details: https://events.drupal.org/baltimore2017/community-discussion

  • Tuesday, 12-1pm, max 45 participants

  • Tuesday, 2:15-3:15pm, max 15

  • Tuesday, 5-6pm, max 15

  • Wednesday, 2:15-3:15pm, max 15

  • Wednesday, 3:45-4:45pm, max 15

  • Thursday, 10:45-11:45am, max 15

  • Thursday, 1-2pm, max 45

Virtual Meetings after DrupalCon

Sign Up Here: https://events.drupal.org/virtual/community-discussions
        

  • Tuesday, May 9: 4pm EDT / 1pm PDT / 9pm BST / 10pm CEST / 6am +1 AEST

  • Wednesday, May 10: 8am EDT / 1pm BST / 2pm CEST / 5:30pm IST / 10pm AEST

  • Thursday, May 11: 9:30am EDT / 2:30pm BST / 3:30pm CEST / 7pm IST / 11:30pm AEST

  • Friday, May 12: 2pm EDT / 11am PDT / 7pm BST / 8pm CEST / 11:30pm IST

  • Tuesday, May 16: 8pm EDT / 5pm PDT / 10am AEST

  • Wednesday, May 17: 12pm EDT / 9am PDT / 5pm BST / 6pm CEST / 9:30pm IST

  • Thursday, May 18: 3pm EDT / 12pm PDT / 8pm BST / 9pm CEST

Ground Rules for Community Discussions

Key Principles of Nonviolent Communication

  • Responsibility for Our Feelings: We aim to move away from blame, shame, judgment, and criticism by connecting our feelings to our own needs. This recognition empowers us to take action to meet our needs instead of waiting for others to change.

  • Responsibility for Our Actions: We aim to recognize our choice in each moment, and take action based on seeing how it would meet our needs to do so; we aim to move away from taking action based on fear, guilt, shame, the desire for reward, or any “should” or “have to.”

  • Prioritizing Connection: We aim to focus on connection instead of immediate solutions, and to trust that connecting with our own and others’ needs is more likely to lead to creating solutions that meet everyone’s needs.

  • Equal Care for Everyone’s Needs: We aim to make requests and not demands; when hearing disagreement with our request, or when disagreeing with another’s request, we aim to work towards solutions that meet everyone’s needs, not just our own, and not just the other person’s.

  • Self-Expression: When expressing ourselves, we aim to speak from the heart, expressing our feelings and needs, and making specific, doable requests rather than demands.

  • Empathic Hearing: When we hear others, we aim to hear the feelings and needs behind the expressions, even when they express judgments or demands.

  • Protective Use of Force: We aim to use force only to protect, not to punish others or get our way without the other’s agreement, and only in situations where the principles above were not sufficient to meet immediate needs for safety. We aim to return to dialogue as soon as safety is re-established

How These Ground Rules Work

  • Ground rules will be stated at the beginning of each session.

  • If you are not in agreement with the ground rules, please do not participate in the session.

  • If a participant is repeatedly disruptive of respectful, productive discussion, they will be asked to leave; if they do not leave, the session will be terminated immediately.

Drupal Core - Critical - Access Bypass - SA-CORE-2017-002

Drupal - Wed, 04/19/2017 - 10:13
Description

This is a critical access bypass vulnerability. A site is only affected by this if all of the following conditions are met:

  • The site has the RESTful Web Services (rest) module enabled.
  • The site allows PATCH requests.
  • An attacker can get or register a user account on the site.

While we don't normally provide security releases for unsupported minor releases, given the potential severity of this issue, we have also provided an 8.2.x release to ensure that sites that have not had a chance to update to 8.3.0 can update safely.

CVE identifier(s) issued
  • A CVE identifier will be requested, and added upon issuance, in accordance with Drupal Security Team processes.
Versions affected
  • Drupal 8 prior to 8.2.8 and 8.3.1.
  • Drupal 7.x is not affected.
Solution
  • If the site is running Drupal 8.2.7 or earlier, upgrade to 8.2.8.
  • If the site is running Drupal 8.3.0, upgrade to 8.3.1.

Also see the Drupal core project page.

Reported by Fixed by Coordinated by
  • The Drupal Security team
Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

What's new on Drupal.org? - March 2017

Drupal - Tue, 04/18/2017 - 11:02

Read our Roadmap to understand how this work falls into priorities set by the Drupal Association with direction and collaboration from the Board and community.

The Drupal Association team is gearing up for DrupalCon Baltimore. We're excited to see you there and we'll presenting a panel giving an update on our work since Dublin, and our plans for the coming months.

Drupal.org updates Project application revamp

As we announced in mid-March, new contributors on Drupal.org can now create full projects and releases! Contributors no longer have to wait in the project application queue for a manual review before they are able to contribute projects.

This is a very significant change in the Drupal contribution landscape, and it's something we approached carefully and will continue to monitor over the coming months. Drupal has always had a reputation for a high quality code, and we want to make sure that reputation is preserved with good security signals, project quality signals, and continued incentives for peer code review.

That said, we're very excited to see how this change opens up Drupal to a wider audience of contributors.

Please note that the removal of project applications to create full projects and releases means a change in the security advisory policy (see below for details).

Security Advisory Opt-in and new Security Signals for Projects Are you responsible for the security of your clients' Drupal sites?

Please note that Drupal's security advisory coverage policy has changed. Security advisory coverage for contributed projects is now only available for projects that have both opted in to receive coverage and made a stable release. You can see which projects have opted in by checking their project pages. If you have questions, please contact security@drupal.org.

Because users may now create full projects and releases without opting in to security advisory coverage, it's critically important that we provide good security signals to users evaluating projects on Drupal.org. This is why we've added a security coverage warning to projects that aren't opted in to coverage.

We've also:

2017 Community Elections Update

The 2017 elections for the community-at-large seat on the board were held successfully in March. Drupal Association community board elections are conducted with the Instant Runoff Voting system. This voting methodology requires that voters rank their preferred candidates on their ballot, and we've heard that this system has been somewhat unwieldy in the past.

Each year we try to improve the voter experience and so this year we deployed a new drag-and-drop ballot.

Finally, we want to congratulate our newest board member Ryan Szrama!

Better international datetime support throughout Drupal.org

Drupal.org has grown organically over the course of more than a decade, and as features have been built out they were not always consistent in their display of datetime information. While it sometimes makes sense to have a few different formats for displaying date and time, many of the formats in use were simply arbitrary historical decisions.

As a quality of life improvement, especially for users outside of the USA, we've standardized the datetime format used on Drupal.org. That format is: DD MMM YYYY - hh:mm (UTC±h). For example: 11 Aug 2016 - 16:42 (UTC+8)

DrupalCI CSS Lint check style results

When we implemented coding standards testing in DrupalCI in February we were not able to add CSS Lint testing until the CSSLint configuration file in core was fixed. That issue was fixed in late February and so we added CSSLint to support coding standards testing for CSS at the beginning of March.

Cleaning up coding standards results

The addition of coding standards results to DrupalCI means that Drupal.org is now storing even more test data about the code we test on Drupal.org. Our initial implementation of coding standards testing did not include clean up of older results, and so to preserve database space and testing resources, we implemented some clean-up routines in March. In particular we are now:

  • Cleaning up all results for closed issues
  • For custom one-off tests, keeping results for 30 days to match what is shown on project’s automated testing tab
  • For tests triggered on a schedule or commit, keeping the most recent per-environment per-branch, and keeping anything less than 24h old
Infrastructure Protecting Git services

We experienced some minor Git outages in March, due to malicious authentication attempts. To mitigate these issues in the future, we've implemented fail2ban rules to protect Git authentication. This should improve the stability and uptime of Git services for all developers on Drupal.org.

We want to thank Drupal.org infrastructure volunteer mlhess for his assistance with this.

Community Initiatives Contrib Documentation Migration

New tools for Documentation have been available on Drupal.org for more than half a year. While most of the core documentation has been migrated to the new system, we are still encouraging Contrib maintainers to migrate their docs.

To make it easier for contrib project maintainers to migrate their documentation to the new documentation tools, we've made two improvements:

———

As always, we’d like to say thanks to all the volunteers who work with us, and to the Drupal Association Supporters, who made it possible for us to work on these projects. In particular we want to thank:

If you would like to support our work as an individual or an organization, consider becoming a member of the Drupal Association.

Follow us on Twitter for regular updates: @drupal_org, @drupal_infra

Drupal 8 core upcoming critical release PSA-2017-001

Drupal - Mon, 04/17/2017 - 08:47
  • Advisory ID: DRUPAL-PSA-2017-001
  • Project: Drupal core
  • Version: 8.x
  • Date: 2017-Apr-17
Description

There will be a security release of Drupal 8.3.x and 8.2.x on April 19th 2017 between
17:00 - 18:00 UTC
that will fix a critical vulnerability. While we don't normally provide security releases for unsupported minor releases, given the potential severity, the 8.2.x release includes the fix for sites which have not had a chance to update to 8.3.0. The Drupal Security Team urges you to reserve time for core updates at that time because exploits are expected to be developed within hours or days. Security release announcements will appear at the standard announcement locations.

This vulnerability does not affect all Drupal 8 sites; it only affects sites with certain configurations. It requires authenticated user access to exploit. The security release announcement made on April 19th 2017, will make it clear which configurations are affected. If this vulnerability affects your site, you will need to update. Please set aside time on Wednesday to look into this update.

Neither the Security Team, nor Security Team members, nor any Drupal-related company are able to release any more information about this vulnerability until the announcement is made in accordance with our security policies and responsible disclosure best practices.

We provide pre-release warnings when we believe the security risk is high and the steps to exploit are scriptable

Drupal 7 core is not affected by this issue. Contact and More Information

The Drupal security team can be reached at security at Drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity.

Technical Advisory Committee Update

Drupal - Tue, 04/11/2017 - 10:12

In October of last year the Technical Advisory Committee was formed to evaluate options for the developer tools we use on Drupal.org. The TAC consists of Angie Byron, Moshe Weitzman, and Steve Francia, acting as advisors to Megan Sanicki, the Executive Director of the Drupal Association.

The TAC's mandate is to recommend a direction for the future of our tools on Drupal.org. Megan will evaluate this recommendation, make a decision, and prioritize that work in the development roadmap of the Drupal Association engineering team.

What is the motivation behind looking at our developer tools now?

Close followers of the Drupal project will have noticed a trend in the last several months. From Dries' announcement of easy upgrades forever, to the revamp of the project application process, to the discussion about making tools for site builders— there is a unifying theme: broadening the reach of Drupal.

This is the same motivation that underlies this evaluation of our developer tools, and defines the goals and constraints of this initiative:

  • Adopt a developer workflow that will be familiar to the millions of developers outside our community
  • Preserve those unique elements of how we collaborate that have made the Drupal project so successful
  • If possible, leverage an expert partner who will help keeping our tooling up to date as open source collaboration tools continue to evolve

This means looking at a number of elements of the Drupal.org developer tool stack:

  • The underlying git service
  • How we tag and package releases
  • The contribution workflow (patch vs. pull request)
  • Project management workflows (the issue queues and tags)
  • CI integration
  • Maintainership
  • Project pages

If this looks like a tremendous undertaking - that's because it is. But there are some things we already know:

  • Drupal.org should continue to be the home of project pages
  • We should adopt a pull request workflow (and ideally we want to be able continue to accept patches as well, at least in the interim)
  • We should move contrib projects to semver, following core's lead
  • We want to preserve our familiar understanding of maintainership
  • We want to avoided forked code and forked conversation
  • We want to ensure the security team still has the tools they need to provide their service to the community

We also know that whatever decision is made, these changes cannot happen all at once. We'll need to take a progressive approach to the implementation, and focus on the parts of the stack that need to change together, so that we don't bite off more than we can chew.

What options are being considered?

At this time, the technical advisory committee is considering three options as they prepare to make their recommendation. The options are: GitLab, which offers both self-hosted and SaaS options; GitHub, which has recently been adding long-requested new features; or continuing to evolve our custom-built tooling, perhaps via issue workspaces.

GitLab

GitLab is the up-and-comer among Git hosts. GitLab can be self hosted using either their community or enterprise editions, or repositories can be hosted at GitLab.com. Though they recently stumbled, they have been notably open and transparent about their efforts to build a leading collaboration platform.

Gitlab is itself open-source, and has just released its 9.0 edition. GitLab has aggressively pursued the latest in development tools and workflow features, including project management tools, a ui for merge conflict resolution with in-line commenting and cherry-picking, docker registries for projects, integration with CI tools, and even Gitter, an IRC alternative for real-time collaboration.

GitHub

For quite some time, GitHub was the only real player in git repository hosting outside of rolling a custom solution (as we did for Drupal.org). Over the years it has become the home of many open source projects, and while most of those don't match the sheer scale of Drupal in terms of codebase size and number of contributors, there are certainly other major projects that have made their home there.

However, for all of its presence and longevity in the open source world, there are very few options for customizing its toolset for our needs, and we could no longer self-host our canonical repositories. The Drupal project would need to adapt to GitHub, rather than the other way around.
 

That said, in recent months, GitHub has been putting a strong focus on feature development, adding a number of new features including: automated licensing information,  protected branches, and review requests.

Custom tooling

We also must consider that the tools we have now are what built Drupal into what it is today. A great deal of work has gone into our existing developer tools over the years, and we have some unique workflows that would have to be given up if we switched over to a tooling partner. An idea like the issue workspaces proposal would allow us to achieve the goal of modernizing our tools, and likely do so in a way that is better tailored to those unique things about the Drupal workflow that we may want to preserve. However, doubling down on building our own tooling would come at a cost of continuing to be unfamiliar to the outside development community, and dependent on an internal team's ability to keep up with the featureset of these larger players.

Each of these three options would be a compromise between reaching outward and creating familiarity, and looking inward to preserve the Drupal specific workflows that have brought the project to where it is today.

What have we learned so far?

The TAC has conducted their own internal evaluation of the options as well as worked with Drupal Association staff in a two day exploratory session at the end of last year. The primary focus was to identify and triage gaps between the different toolsets in the following areas:

  • Migration effort
  • Project management
  • Code workflow
  • Project handling
  • Testing
  • Git Back-end/Packaging
  • Integrations beyond tools

This initial study also looked at the impact of each option on Drupal community values, and some key risks associated with each.

What comes next?

The next step for the TAC is to make their formal recommendation to the Executive Director of the Drupal Association. At that point, she will direct staff to validate the recommendation by prototyping the recommended solution. Once the recommendation has been validated, Megan will make a final decision and prioritize the work to fully implement this option, relative to other Drupal Association imperatives.

In the comments below, we would love to hear from the community:

What aspects of the way the Drupal community collaborates are the most important to you? What workflow elements do you feel need to be preserved in the transition to any new tooling option?

Drupal 8.3.0 is now available

Drupal - Wed, 04/05/2017 - 15:03

Drupal 8.3.0, the third minor release of Drupal 8, is now available. With Drupal 8, we made significant changes in our release process, adopting semantic versioning and scheduled feature releases. This allows us to make extensive improvements to Drupal 8 in a timely fashion while still providing backwards compatibility.

What's new in Drupal 8.3.0?

This new version includes improvements to authoring experience, site administration, REST support, and a stable version of the BigPipe module. It also includes new experimental modules to abstract workflow functionality, to lay out content types differently (e.g. articles are two column vs. press releases are three column), and to provide a general layout API for contributed modules. Many smaller improvements for the experimental Content Moderation module are included as well. (Experimental modules are provided with Drupal core for testing purposes, but are not yet fully supported.)

Download Drupal 8.3.0

New and improved content authoring

Drupal 8.3 ships with the updated CKEditor 4.6, which contains a host of improvements, including better paste from Word, and a new default skin that better matches Drupal's Seven administration theme. We've also added the AutoGrow plugin, to better utilize larger screen sizes.

Quick editing images now supports drag and drop.

Site building and administrative improvements

Drupal 8.3 ships with a redesigned admin status report, to better surface important status messages for your site.

Other incremental enhancements include:

  • The Views listing page is now standardized with other administrative listings.
  • The "Allowed HTML tags" input has been converted to a textarea, which significantly improves the usability of HTML filter configuration (and thereby makes it easier to configure filters securely.)
  • The Content and People overview pages' Views filters have been rearranged to match the column order of the listing, for more intuitive filtering.
  • Image fields are now limited to only accepting images, so that users on mobile clients are not offered a confusing and non-functional video upload option.
BigPipe for perceived performance

The Drupal 8 BigPipe module (now stable!) provides an advanced implementation of Facebook's BigPipe page rendering strategy, leading to greatly improved perceived performance for pages with dynamic, personalized, or uncacheable content. See the BigPipe documentation.

The core BigPipe improvements introduced in 8.3.0 are also utilized by the Sessionless BigPipe contributed module to use the same technique for serving the first (yet uncached) response to anonymous visitors.

Platform features for web services

Drupal 8.3 continues to expand Drupal's support for web services that benefit decoupled sites and applications, with bug fixes, improved responses, and new features. It is now possible to register users from the REST API, 403 responses now return a reason why access was denied, for greatly improved developer experience, and anonymous REST API performance has been increased by 60% when utilizing the internal page cache. The REST API also got a massive overhaul of its test coverage.

Experimental: Choose different form and view display layouts for your entity types

The new experimental Field Layout module provides the ability for site builders to rearrange fields on content types, block types, etc. into new regions, for both the form and display, on the same forms provided by the normal field user interface.

Field Layout also uses the new the Layout Discovery module, which provides an API for modules or themes to register layouts as well as five common default layouts. By providing this API in core, we help make it possible for core and contributed layout solutions to be compatible with each other. The following contributed modules already have development versions that support the new API:

Experimental: Content moderation improvements

The Content Moderation module included with Drupal 8.2.x is now accompanied by a more abstract Workflows module that took over the underlying workflow functionality and API. This allows additional modules to apply workflows that do not deal with content publication, such as for users or products. The Workflows module provides a user interface to package states with their transitions in a workflow, which Content Moderation can then apply to content, making configuration much easier.

There are several other smaller improvements. It is now possible to moderate non-translatable entity types, entity types without bundles, and any entity type that supports publishing (not just nodes). Moderation states are also reverted when revisions are reverted.

What does this mean to me? Drupal 8 site owners

Update to 8.3.0 to continue receiving bug and security fixes. The next bugfix release (8.3.1) is scheduled for May 3, 2017.

Updating your site from 8.2.7 to 8.3.0 with update.php is exactly the same as updating from 8.2.6 to 8.2.7. Modules, themes, and translations may need small changes for this minor release, so test the update carefully before updating your production site.

Drupal 7 site owners

Drupal 7 is still fully supported and will continue to receive bug and security fixes throughout all minor releases of Drupal 8.

Most high-priority migrations from Drupal 7 to 8 are now available, but the migration path is still not complete, especially for multilingual sites, so you may encounter errors or missing migrations when you try to migrate. That said, since your Drupal 7 site can remain up and running while you test migrating into a new Drupal 8 site, you can help us stabilize the Drupal 7 to Drupal 8 migration path! Testing and bug reports from your real-world Drupal 7 sites will help us stabilize this functionality sooner for everyone. (Search the known issues.)

Drupal 6 site owners

Drupal 6 is not supported anymore. Create a Drupal 8 site and try migrating your data into it as soon as possible. Your Drupal 6 site can still remain up and running while you test migrating your Drupal 6 data into your new Drupal 8 site. Core now provides migrations for most Drupal 6 data, but the migrations of multilingual functionality, references, and dates in particular are not complete. If you find a new bug not covered by the known issues with the experimental Migrate module suite, your detailed bug report with steps to reproduce is a big help!

Translation, module, and theme contributors

Minor releases like Drupal 8.3.0 include backwards-compatible API additions for developers as well as new features. Read the 8.3.0 release notes for more details on the improvements for developers in this release.

Since minor releases are backwards-compatible, modules, themes, and translations that supported Drupal 8.2.x and Drupal 8.1.x will be compatible with 8.3.x as well. However, the new version does include some changes to strings, user interfaces, and internal APIs (as well as more significant changes to experimental modules). This means that some small updates may be required for your translations, modules, and themes. See the announcement of the 8.3.0 release candidate for more background information.

Working through the concerns of our community

Drupal - Fri, 03/31/2017 - 08:54

This is a joint statement from project lead Dries Buytaert and Megan Sanicki, Drupal Association Executive Director.

Over the last week, the Drupal community has been in a debate over the various decisions made by us in relation to long-time Drupal developer Larry Garfield. As with any such decisions, and especially due to the circumstances of this one, there has been controversy, misinformation and rumors, as well as healthy conversation and debate. Many people feel hurt, worried, and confused. The fact that this matter became very public and divisive greatly saddens all of us involved, especially as we can see the pain it has caused many.

First off, we want to apologize for not responding sooner. We had to take a pause to process the community’s reaction.  We also wanted to take the time to talk to community members to make sure all of the concerns were heard and understood. This was further complicated by the fact that we don't have a playbook for how to respond in unusual situations like this. We also want to acknowledge that our communication has not been as clear as it should be on this matter, and we are sorry for the added confusion.

We want to thank all of the community members who stepped in to help. Many spent days helping other community members by listening, hosting discussions to foster healthy, respectful conversations, and more. You have helped many people and your caring acts reminded us once again why we love to serve the community and why it is so special.

Over the last week, we talked to many people and read hundreds of posts in various channels. These are some of the things that we heard:

  • People are afraid that they will be asked to leave the community because of their beliefs or sexual lifestyles.

  • There are concerns about Drupal leadership playing "thought police" on what are and are not acceptable viewpoints to hold.

  • People want to hear more about the timeline, information gathered, and how decisions were made.

  • People don't understand why there weren’t any ramifications for those who participated in gathering information about Larry's private life.

  • People believe Dries has too much authority.

  • People believe that a decision this complex should not be made by a single individual.

And we heard much more.

We know this has been difficult for all involved. There is no quick solution to the current situation; it will take time to heal, but we want to make a start today by providing better insight into our decision-making process, answering questions with the FAQ found below, and by placing a call for improvements in our governance, conflict-resolution processes, and communication.  

Addressing community questions and concerns

One of the main concerns that has been voiced is that a long-standing member of the Drupal community was removed, based solely on his beliefs being outside the "norm". We feel this is not representative of the situation.

We want to strongly emphasize that Drupal is an open-minded and inclusive community, and we welcome people of all backgrounds. Our community’s diversity is something to cherish and celebrate as well as protect.  We apologize for any anxiety we caused you and reiterate that our decision was not based on anyone’s sexual practices.

Dries and Megan based their decisions on information from a variety of sources, including the Community Working Group and Larry himself. This information included:

(a) reports, both formal and informal
(b) some of Larry's online interactions, both on and off Drupal.org
(c) information provided by Larry during subsequent discussions to get clarity
(d) information from one or more members-only sites.
It should be strongly noted that we do not condone the manner in which this last source of information was gathered by members of our community.  

Insights from this collection of information caused us to take action, particularly given Larry's prominent leadership role in the community, which leads to a much greater impact of his words and actions.

We heard that many would like to better understand the timeline, information gathered, and how decisions were made. While the news of last week was a complete surprise to most, it is important to note that this has been a careful, and deliberate process that has been going on since October 2016. Following the Drupal community's governance, the Community Working Group attempted to provide conflict resolution. When it became clear that some of the issues raised went beyond the scope of their charter, they determined that it was appropriate for the matter to be escalated to Dries, as project lead. This was consistent with their existing policy and process.

Dries discussed the information from the Community Working Group with Megan and some board members. Dries, as project lead, made the decision about Larry’s role in the project during this discussion.  

Some have asked why Larry was removed from the community and not just from his leadership roles. The answer is that Larry had indicated on several occasions that he was drawing down his involvement in the Drupal project, and that context helped inform Dries’ decision.

Dries, with the support of the Community Working Group, had the first of what was intended to be a number of conversations to resolve any remaining concerns.

Megan was informed about Dries’ decision, and also reviewed the information provided by the Community Working Group. Based on that information, Megan made the operational decision to remove Larry’s DrupalCon session and concluded his track chair role.

Larry appealed Megan’s decision to the board, which only has oversight of the Drupal Association. They reviewed the Community Working Group information and Larry’s personal statements, met in a special Executive Session attended by all board members, and upheld Megan’s decision. Dries recused himself from this vote, so the board could make its decision independently.

After the appeal process, Larry chose to publish his own account of what happened, effectively ending the process in the middle of what we expected to be a series of constructive discussions. This resulted in several loose ends.

After Larry’s second blog post, on Tuesday, March 28th, he reached out privately to Dries to discuss how to resolve matters and find the best way forward.

We remain committed to working on closure for this situation with care and respect for everyone involved.  Dries and the Community Working Group hope to have a private discussion with Larry in the coming weeks.

Many have also expressed anger over how the information about Larry came to light, and whether there will be consequences for those who participated in gathering information about his private life. The Community Working Group is currently handling this situation through their standard process.

What needs to change

We are fortunate that we do have governance in place. We have never encountered a situation like this before, where a decision this complex had to be escalated and made. This extraordinary situation highlighted areas that we need to improve. From our own observations and what we heard from the community, we identified some specific areas of improvement (but by no means all):

  • Diversity, equality, and inclusivity issues are complex and require new perspectives and approaches, especially as we assess and improve our Code of Conduct.

  • It is not healthy or wise to escalate difficult decisions about code of conduct or community membership solely to the project lead.

  • We need to clearly define our values so that everyone knows and agrees to the context in which the community works together.

  • We need to figure out how to balance transparency with the need to maintain a safe space and provide confidentiality for individuals in order to resolve conflicts in a way that causes minimal disruption to our community.

There is a lot to address. We will launch several initiatives to find solutions to the problems above.  We want to collaborate with the community, the Drupal Association, and outside experts on these efforts. It is important that we take these steps. We value our special community and we want to make sure that it has the right structure and sound governance to remain healthy and vibrant.

We want to begin healing to start right away and that starts with us talking more with the community. We will host online meetings and a meeting at DrupalCon Baltimore on these topics where we can have a healthy dialogue. This will provide community members the opportunity to talk directly with the Community Working Group, Megan, and Dries to propose solutions to some of the governance challenges that brought us here.

Finally, we want to acknowledge this has been a very difficult and unprecedented situation. We realize not everyone will agree with our decisions, but we hope all can understand the care we took in deliberating and the intention behind our actions. We appreciate the community’s patience on this matter, and we look forward to taking these steps in collaboration with you.

----

FAQ

When did the conflict resolution process start?

  • October of 2016.

Who is responsible for what decision?

  • Dries, as project lead, made the decision about Larry’s role in the project after the Community Working Group escalated to him when they felt they could not resolve the issues surrounding this matter.

  • Executive Director of the Drupal Association Megan Sanicki made the decision to to remove Larry’s speaking and track chairmanship at DrupalCon.

  • Larry appealed the DrupalCon decision, which then went to the Drupal Association board who reviewed material provided by the Community Working Group along with Larry’s statements. They upheld Megan’s decision.  Dries recused himself from this vote.

What was the process followed for each decision?

  • The Community Working Group, which is part of Drupal’s governance structure, provided conflict resolution. When it became clear that some of the issues raised went beyond the scope of their charter, they determined that it was appropriate for the matter to be escalated to Dries. This is consistent with their existing policy and process.

  • Dries discussed the information from the Community Working Group with Megan, and some board members. Dries also met with Larry. Larry had indicated on several occasions that he was drawing down his involvement in the Drupal project. That context informed Dries' decision. It is also important to note that Dries intended to have more discussions with Larry to determine what the decision looked like, but those conversations ended when Larry chose to post publicly.

  • Megan was informed about Dries’ decision and also reviewed the information provided by the Community Working Group. Based on Dries’ decision and information learned from the Community Working Group materials, Megan made the operational decision to remove Larry’s DrupalCon session and concluded his track chair role.

  • Larry appealed Megan’s decision to the board, who only have oversight of Drupal Association. They reviewed the Community Working Group information and Larry’s personal statements and upheld Megan’s decision.  Note: Dries recused himself.

What information was used to inform the decisions?

  • (a) reports, both formal and informal, (b) some of Larry's online interactions, both on and off Drupal.org, (c) information provided by Larry during subsequent discussions to get clarity, and (d) information from one or more members-only sites. It should be strongly noted that we do not condone the manner in which this last source of information was gathered by members of our community.   

Did Dries overrule the Community Working Group?

  • No, he did not. The process is designed so that the Community Working Group can escalate issues to Dries if they cannot be resolved. This process was followed.

Is the Drupal project “against” people who practice BDSM or other non-mainstream sexual practices?

  • Absolutely not. We are an open-minded and inclusive community.

Will there be repercussions for Klaus Purer’s conduct?

  • The Community Working Group is handling this situation through their standard process.

2017 Drupal Association at-large election winner announced

Drupal - Mon, 03/27/2017 - 08:51

*/

The staff and board of the Drupal Association would like to congratulate our newest board member:

Ryan Szrama.

Thank you, Ryan, for stepping forward to serve the Drupal community. On behalf of the community I also want to thank the 13 candidates who put themselves out there in service of Drupal and nominated themselves. We are grateful that our community has so many brave and generous people willing to contribute this way.

Ryan's election to the board represents the sixth year of elections to a community-at-large seat on the Drupal Association board. Each year we've focused on improving the elections process, and this year was no different. We focused on two goals: 

  1. Improve the user experience of participating in the elections process. 
    • We added more in-line help materials throughout the elections process.
      • For candidates, we added information about the responsibilities of a board member to the nomination form, as well as a video message from the Executive Director.
      • For voters we improved the elections navigation, and provided more educational materials about the IRV voting process.
    • We implemented a drag and drop ballot, to make it easier for voters to rank candidates. 
  2. Make it easier to get to know the candidates.
    • We updated the candidate profile form, to ask more detailed questions to help voters get to know the candidates. 
    • Based on feedback from previous years, we eliminated the three virtual meet-the-candidates sessions, in favor of giving each candidate the option to post a statement-of-candidacy video.  In conjunction with the question and answer section on each candidate profile, we felt this gave the electorate the opportunity to get to know their candidates at their own pace and on their own terms. 

Our next steps will be to reach out to the candidates for their evaluation of the elections experience.

We also want to hear from the voters. Please tell us about your experience with the elections process in the comments below. Your feedback is important to us so that we can make the 2018 elections process even better. 

About the Elections Methodology: Instant Run-off Voting(IRV)

Elections for the Community-at-large positions on the Drupal Association board are conducted through Instant Run-off Voting. This means that voters can rank candidates according to their preference. When tabulating ballots, the voters' top-ranked choices are considered first. If no candidate has more than 50% of the vote, the candidate with the lowest votes is eliminated. Then the ballots are tabulated again, with all the ballots that had the eliminated candidate as their first rank now recalculated with their second rank choices. This process is repeated until only two candidates remain and a clear winner can be determined. This voting method helps to ensure that the candidate who is most preferred by the most number of voters is ultimately elected. You can learn more about IRV (also known as Alternative Vote) in this video.

Voting Results

There were 13 candidates in contention for the single vacancy among the two community-at-large seats on the Board. 1,240 voters cast their ballots out of a pool of 94,499 eligible voters (1.3%). Voters ranked an average of 3.6 candidates on their ballots. 

The bar charts below show the vote counts for each candidate in each round.
Place the mouse over a bar to see the number of votes.

  • Yellow — Votes carried over from the previous round.
  • Green — Votes received in this round.
  • Red — Votes transferred away in this round.

A candidate's votes in a round is the sum of the yellow and green bars.
Since the green and red bars represent votes being transferred, the sum of the
green and red bars is the same.

The exhausted bar represents votes where the voter did not indicate a next
preference and thus there were no candidates to transfer the vote to.

Round 1

(next)

Count of first choices.

Round 2

(prev)(next)

Count after eliminating gurubryan and transferring votes.

Round 3

(prev)(next)

Count after eliminating mehuls and transferring votes.

Round 4

(prev)(next)

Count after eliminating zet and transferring votes.

Round 5

(prev)(next)

Count after eliminating Rahul Seth and transferring votes.

Round 6

(prev)(next)

Count after eliminating redacted and transferring votes.

Round 7

(prev)(next)

Count after eliminating MatthewS and transferring votes.

Round 8

(prev)(next)

Count after eliminating Riaan Burger and transferring votes.

Round 9

(prev)(next)

Count after eliminating johnkennedy and transferring votes.

Round 10

(prev)(next)

Count after eliminating jackniu and transferring votes.

Round 11

(prev)(next)

Count after eliminating ok_lyndsey and transferring votes.

Round 12

(prev)

Count after eliminating Prasad Shir and transferring votes. Candidate rszrama is elected.

Winners

Winner is rszrama.

A Statement from the Executive Director

Drupal - Thu, 03/23/2017 - 15:49

We understand that there is uncertainty and concern in the Drupal community about project founder, Dries Buytaert, asking Larry Garfield to leave the Drupal community, and about the Drupal Association removing Larry's DrupalCon sessions and ending his term as track chair.

We want to be clear that the decision to remove Larry's DrupalCon session and track chair role was not because of his private life or personal beliefs. The Drupal Association stands by our values of inclusivity. Our decision was based on confidential information conveyed in private by many sources. Due to the confidential nature of the situation we cannot and will not disclose any information that may harm any members of our community, including Larry.

This decision followed our established process. As the Executive Director, charged with safekeeping the goodwill of the organization, I made this decision after considering input from various sources including the Community Working Group (CWG) and Drupal Project Lead, Dries Buytaert. Upon Larry’s request for an appeal, the full board reviewed the situation, all the evidence, and statements provided by Larry. After reviewing the entirety of the information available (including information not in the public view) the decision was upheld.

In order to protect everyone involved we cannot comment more, and trust that the community will be understanding.  

We do see that there are many feelings and questions around this DrupalCon decision and we empathize with those community members. We will continue to monitor comments. We are listening.

How Drupal.org fights spam using Distil Networks

Drupal - Wed, 03/22/2017 - 07:45

This case study was written as a collaboration between Drupal Association staff and Technology Supporting Partner Distil Networks.

Drupal.org is the home of one of the largest open source communities in the world. We've been online for more than 13 years and collectively we build the Drupal software, provide support, write documentation, share networking opportunities, and more. The open source spirit pushes the Drupal project forward, and new members are always welcome. It falls to us to maintain our community home and preserve the welcoming atmosphere that leads people to say,"Come for the code, stay for the community."  

As stewards of Drupal.org, it's our responsibility to give the community a voice and welcome everyone who wants to participate in the project. At the same time, there are bad actors who would take advantage of our open community and platform for abusive purposes.

Drupal.org long-standing presence on the web has given it authority in the eyes of search engines. The site hosts millions of pages of content - all generated by our users. This combination of authority and open access for users to create content makes us a very high value target for phishers and spammers.

Spam is a nuisance to our existing community, devalues our project to the newcomers we are hoping to welcome, and left unchecked could degrade our search presence.

Challenges Spammers create bogus accounts to post their junk content

Only registered members can post content to the Drupal.org website, so there's a continuous onslaught of actors attempting to create accounts for the purpose of inserting link spam and other bad content onto the site. In the past, we've implemented a variety of strategies such as content analysis, behavioral analysis, social moderation, and rate limiting. And while these measures have been effective at reducing some of the spam we've seen, the onslaught continues.

The reason for that? Much of our attempted spam is not coming from bots. These are real people using tools to cloak their identity and manually creating accounts en masse. In many cases they may not even post junk content immediately. They will often sit on "sleeper" accounts waiting to be paid by somebody to promote malicious content.

It's too time consuming to manually remove spam content

Spam fighting is also a thankless task. All time spent fighting spam, whether by members of the engineering staff or our incredibly dedicated community volunteers, is time not spent on the project. Spam fighting has an opportunity cost that creates burn-out among staff and volunteers, and is not something we can afford to leave to manual moderation.

Especially when it comes to our community volunteers– they want to spend their time helping people with Drupal technical questions, not deleting spam.

Fake accounts and spam pollute the community engagement metrics

There are 1.9 million user accounts in the Drupal.org database, but using this data to measure community engagement is challenging because of the number of spammer accounts that have been registered over the years. When we have to work around so many illegitimate accounts, it's difficult to determine metrics for community health such as if our legitimate user growth is increasing or decreasing. We need cleaner user account data to give us more reliable community metrics, and help us make informed decisions.

The Solution

Before reaching out to Distil Networks, Drupal.org relied primarily on two modules to help us fight spam. Mollom is a Drupal stand-by—a content analysis tool that looks at what users are posting and compares them against known bad actor patterns. This content analysis helps us identify and block new waves of spam patterns, but it doesn't prevent these waves from being posted in the first place.

The second module we use is Honeypot, which uses a combination of honeypot and rate limiting methods to prevent bot spam. Honeypot does a good job in preventing mass spam attacks by bots, but when real people are creating the underlying accounts honeypot can't help us.

As we researched ways to prevent spam, we discovered that all of these bad actors we wanted to keep out had one thing in common—they are hiding their identities behind proxies. This prevents us from simply blacklisting certain ip addresses or ranges. So instead, we began researching ways to unmask the users behind these proxies and block them before they can even create an account.

Our research led us to Distil Networks. We now run the Drupal.org registration pages(and only the registration pages) through the Distil Cloud CDN. Distil's service gathers device fingerprints for the users trying to create the accounts, and we're able to leverage those fingerprints to block users who would otherwise generate dozens or hundreds of accounts by rotating through proxies. This fingerprinting process is limited to a hashed, unique identifier and only affects our registration process, to preserve the privacy of our legitimate users.

What the Distil data shows

After enabling Distil's service for our registration process we were able to capture fingerprints for about 20,000 account registrations over the course of nine months. We were immediately able to identify more than 10% of those account registrations as duplicate registrations by the same user, hiding behind a proxy. As we dug into the data further, we realized that thousands of the spam accounts that spammers are attempting to register are actually created by only 200-300 real individuals.

By blocking these 200-300 individuals by their Distil fingerprint, we can block thousands of account registrations, and tens of thousands of spam posts that would have been created had these 'sleeper accounts' been activated.

Results

Even with Distil's sophisticated profiling tool available to us, we knew that the spam fighting process would continue to have a manual component. In the first place, there are still thousands of 'sleeper' accounts registered before we implemented Distil that could be activated. And secondly, we know that we cannot simply rely on proxy detection and fingerprint collisions to identify spam accounts. Some of our users are in countries where a proxy is the only way to access a free and open internet. Other users are in environments that have identical device fingerprints and a shared IP, such as a classroom computer lab.

However, by taking advantage of the tools that Distil offers, we can now stop many of the account registrations at the source. In the same time that it once took us to moderate a single new user account that had just posted spam, we can now block a unique id that would have been used to create a dozen or even a hundred more accounts.

We've seen trends in our account registration logs that show that the new methods are working. As we block spammers in ways they can't circumvent through proxies, their ability to register multiple accounts diminishes. Without being able to mass register accounts to later activate when selling link spam, Drupal.org becomes a less viable target.

While some spam still gets through, whether from old sleeper accounts, or lucky new spammers that manage to slip by, the overall reduction in spam has been significant. This lets our volunteers and internal staff direct more of their efforts at moving the project forward, rather than fighting spam.  

With fewer illegitimate account registrations, we're also able to improve the metrics we use to measure our community health and engagement, by lowering the noise-to-signal ratio in user activity.

Conclusion

We want to thank Distil Networks for joining the Drupal Association as a Premium Technology Supporter. The tools that Distil Networks provide enable us to better take care of the home of the community. Fighting spam is a never ending challenge: as long as there is a financial incentive to posting spam, bad actors will continue to evolve their methods, but with a partner like Distil Networks we are now equipped to stay one step ahead.

To learn more about how Drupal.org and Distil Networks partnered to tackle spam, and to learn how you could leverage a similar solution for your own site, please join us at our webinar on April 5th, at 10am Pacific.

Distil Networks will be joining us at DrupalCon Baltimore from April 24-28th. We invite the community to join us there and learn more about our partnership.

Goodbye Project Applications, Hello Security Advisory Opt-in

Drupal - Fri, 03/17/2017 - 15:12

Any user on Drupal.org who has accepted our Git usage policy may now create full projects with releases. This is a big change in policy for the Drupal project, representing an evolution of the contribution ecosystem in the past half a decade.

What was the Project Application Process?

Ever since the days when Drupal's code was hosted in CVS there has been some form of project application process in the Drupal Community. To prevent duplicate, low-quality, insecure, or otherwise undesirable projects from flooding Drupal, users would submit sandbox projects to an application queue to be reviewed by a group of volunteers.

After resolving any issues raised in this review process, the user would be given the git vetted role, allowing them to promote their sandbox to a full project, claim a namespace, and create releases. Once a user had been vetted for their first project, they would remain vetted and be able to promote any future projects on their own, without submitting an additional application.

The Problem

Unfortunately, though the project application process was created with the best of intentions, in the long term it proved not to be sustainable. Drupal grew too fast for a group of volunteer reviewers to keep up with reviewing new projects, and at times there were applications waiting in queue for 6 months to 1 year, or even more. That is much too slow in the world of software development.

This put Drupal in a difficult situation. After years of subjecting new projects and contributors to a rigorous standard of peer review, Drupal has a well-deserved reputation for code quality and security. Unlike many open source projects, we largely avoided the problem of having many duplicate modules that exist to serve the same purpose. We unified our community’s effort, and kept up a culture of collaboration and peer review. At the same time, many would-be contributors were unable or unwilling to navigate the application process and so simply chose not to contribute.

The question became, how could we preserve the emphasis on quality while at the same time removing the barrier to contribution that the application process had become?

Constraints on a solution

Opening the contribution gates while retaining strong signals about code quality and security was a tricky problem. We established three constraints on a solution:

  1. We need to welcome new contributors, and eliminate the walls that prevent contribution.
  2. We need to continue to send strong signals about security coverage to users evaluating whether to use modules from Drupal.org.
  3. We need to continue our strong emphasis on quality and collaboration through changes to project discovery that will provide new signals about code quality, and by providing incentives and credit for peer review.
The Solution

In collaboration with the community, the security team, members of the board, and staff we outlined a solution in four phases:

Phase 1: Send strong signals about security advisory coverage.
  • We updated project pages to include messaging and a shield icon to indicate whether a project received security advisory coverage from the security team.
  • We now serve security advisory coverage information in the Updates status information provided by Drupal.org, and we're working on a patch to display that information directly on the updates page of users' Drupal sites.

Here are some examples of what these security signals look like on project pages:

If a project is not opted in to security advisory coverage, this message will appear at the top of the project page:

And this one will appear near the download table:

If a project has opted in, this message will appear near the download table:

And covered releases will show the coverage icon (note how the stable 7.x release has coverage and the 8.x release candidate does not):

Phase 2: Set up an opt-in process for security advisory coverage
  • Previously any project with a stable release would receive security advisory coverage from the security team. As we opened the gates for anyone to promote full projects, the security team needed an opt in process so that they could enforce an extra level of vetting on projects that wish to receive advisory coverage.
  • We agreed to repurpose the project application queue to be a queue for vetting users for the ability to opt their projects in to receive security advisory coverage. Now that this process has been decoupled from creating full projects, the security team may revise it in future–in collaboration with staff and the community.
  • Now a project maintainer must opt in their project to receive advisory coverage and make a stable release in order to receive security advisory coverage from the security team.

Once a maintainer has been vetted by the security advisory opt in process, they can edit their project and use this field set to opt-in:

Phase 3: Open the gate to allow users to create full projects with releases without project applications.

This is the milestone we've just reached!

Phase 4: Provide both automated code quality signals, as well as incentives for peer review of projects - and factor these into project discovery
  • We are working on this phase of the project in the issue queues, and we appreciate your feedback and ideas!
What is the new process?

So in the end - what is the new process if you want to make a contribution by hosting a project on Drupal.org?

  1. You must have a Drupal.org account, and you must accept the git terms of service.
  2. You can create a sandbox or a full project
  • Note: We still strongly recommend that project maintainers begin with sandbox projects, until they are sure they will be able to commit to supporting the project as a full project, and until the code is nearly ready for an initial release.
  • That said, you can promote a sandbox project to a full project at any time, to reserve your name space and begin making releases.

At this point, you will have a full project on Drupal.org, and will be able to make releases that anyone can use on their Drupal site. The project will not receive security advisory coverage, and a warning that the project is not covered will appear on the project page and in the updates information.

If you want to receive security advisory coverage for your project, you will need to take these additional steps:

  1. You must apply for vetted status in the security advisory coverage queue.
  2. Members of the security team or other volunteers will review your application - and may suggest changes to your project.
  3. Once feedback is resolved, you will be granted the vetted role and be able to opt in this project, and any future projects you create, to receive security advisory coverage.
    • Note: Only *stable* releases receive security advisory coverage, so even after opting your project in you will not receive the advisory coverage shield except on stable releases.
What comes next?

Now that the project application process is no more, the gates are open. We are already seeing an uptick in projects created on Drupal.org, and have seen some projects that had migrated to other places (like GitHub) migrate back to Drupal.org. We can expect to see contributions from some great developers who previously felt gate-kept out of the community. We will also see an uptick in contributions that need work, from new developers and others who are still learning Drupal best practices.

That is why our next focus will be on providing good code quality signals for projects on Drupal.org. We want to provide both automated signals of code quality, and new incentives for peer review from existing members of the community. We're outlining that plan in the issue queues, and we welcome your feedback and contributions.

We also still have work to do to communicate this well. This is a big change for the Drupal community and so we want to make people aware of this change in every channel that we can.

Finally, after such a significant change, we're going to need to monitor the contrib ecosystem closely. We're going to learn a lot about the project in the next several months, and it's likely there will be additional follow ups and other changes that we'll need to make.  

Special Thanks

There are many, many contributors on Drupal.org who have put in time and effort to help make the contribution process better for new contributors to Drupal - the deepest thanks to all of you for your insight and feedback. We'd also like to specifically thank those who participated in the Project Application Revamp, including:

Drupal Core - Multiple Vulnerabilities - SA-CORE-2017-001

Drupal - Wed, 03/15/2017 - 12:24

Drupal 8.2.7, a maintenance release which contains fixes for security vulnerabilities, is now available for download.

Download Drupal 8.2.7

Upgrading your existing Drupal 8 sites is strongly recommended. There are no new features nor non-security-related bug fixes in this release. See the 8.2.7 release notes for details on important changes and known issues affecting this release. Read on for details of the security vulnerabilities that were fixed in this release.

  • Advisory ID: DRUPAL-SA-CORE-2017-001
  • Project: Drupal core
  • Version: 8.x
  • Date: 2017-March-15
Description Editor module incorrectly checks access to inline private files - Drupal 8 - Access Bypass - Critical - CVE-2017-6377

When adding a private file via a configured text editor (like CKEditor), the editor will not correctly check access for the file being attached, resulting in an access bypass.

Some admin paths were not protected with a CSRF token - Drupal 8 - Cross Site Request Forgery - Moderately Critical - CVE-2017-6379

Some administrative paths did not include protection for CSRF. This would allow an attacker to disable some blocks on a site. This issue is mitigated by the fact that users would have to know the block ID.

Remote code execution - Drupal 8 - Remote code execution - Moderately Critical - CVE-2017-6381

A 3rd party development library including with Drupal 8 development dependencies is vulnerable to remote code execution.

This is mitigated by the default .htaccess protection against PHP execution, and the fact that Composer development dependencies aren't normal installed.

You might be vulnerable to this if you are running a version of Drupal before 8.2.2. To be sure you aren’t vulnerable, you can remove the /vendor/phpunit directory from the site root of your production deployments.

Solution

Upgrade to Drupal 8.2.7

Reported by Editor module incorrectly checks access to inline private files - Drupal 8 - Access Bypass - Critical - CVE-2017-6377 Some admin paths were not protected with a CSRF token - Drupal 8 - Cross Site Request Forgery - Moderately Critical - CVE-2017-6379 Remote code execution - Drupal 8 - Remote code execution - Moderately Critical - CVE-2017-6381 Fixed by Editor module incorrectly checks access to inline private files - Drupal 8 - Access Bypass - Critical - CVE-2017-6377 Some admin paths were not protected with a CSRF token - Drupal 8 - Cross Site Request Forgery - Moderately Critical - CVE-2017-6379 Remote code execution - Drupal 8 - Remote code execution -Moderately Critical - CVE-2017-6381 Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Making Drupal upgrades easy forever

Drupal - Tue, 03/14/2017 - 09:16

Republished from buytaert.net, please post your comments there.

One of the key reasons that Drupal has been successful is because we always made big, forward-looking changes. As a result, Drupal is one of very few CMSes that has stayed relevant for 15+ years. The downside is that with every major release of Drupal, we've gone through a lot of pain adjusting to these changes. The learning curve and difficult upgrade path from one major version of Drupal to the next (e.g. from Drupal 7 to Drupal 8) has also held back Drupal's momentum. In an ideal world, we'd be able to innovate fast yet provide a smooth learning curve and upgrade path from Drupal 8 to Drupal 9. We believe we've found a way to do both!

Upgrading from Drupal 8.2 to Drupal 8.3

Before we can talk about the upgrade path to Drupal 9, it's important to understand how we do releases in Drupal 8. With the release of Drupal 8, we moved Drupal core to use a continuous innovation model. Rather than having to wait for years to get new features, users now get sizeable advances in functionality every six months. Furthermore, we committed to providing a smooth upgrade for modules, themes, and distributions from one six-month release to the next.

This new approach is starting to work really well. With the 8.1 and 8.2 updates behind us and 8.3 close to release, we have added some stable improvements like BigPipe and a new status report page, as well as experimental improvements for outside-in, workflowslayouts, and more. We also plan to add important media improvements in 8.4.

Most importantly, upgrading from 8.2 to 8.3 for these new features is not much more complicated than simply updating for a bugfix or security release.

Upgrading from Drupal 8 to Drupal 9

After a lot of discussion among the Drupal core committers and developers, and studying projects like Symfony, we believe that the advantages of Drupal's minor upgrade model (e.g. from Drupal 8.2 to Drupal 8.3) can be translated to major upgrades (e.g. from Drupal 8 to Drupal 9). We see a way to keep innovating while providing a smooth upgrade path and learning curve from Drupal 8 to Drupal 9.

Here is how we will accomplish this: we will continue to introduce new features and backwards-compatible changes in Drupal 8 releases. In the process, we sometimes have to deprecate the old systems. Instead of removing old systems, we will keep them in place and encourage module maintainers to update to the new systems. This means that modules and custom code will continue to work. The more we innovate, the more deprecated code there will be in Drupal 8. Over time, maintaining backwards compatibility will become increasingly complex. Eventually, we will reach a point where we simply have too much deprecated code in Drupal 8. At that point, we will choose to remove the deprecated systems and release that as Drupal 9.

This means that Drupal 9.0 should be almost identical to the last Drupal 8 release, minus the deprecated code. It means that when modules take advantage of the latest Drupal 8 APIs and avoid using deprecated code, they should work on Drupal 9. Updating from Drupal 8's latest version to Drupal 9.0.0 should be as easy as updating between minor versions of Drupal 8. It also means that Drupal 9 gives us a clean slate to start innovating more rapidly again.

Why would you upgrade to Drupal 9 then? For the great new features in 9.1. No more features will be added to Drupal 8 after Drupal 9.0. Instead, they will go into Drupal 9.1, 9.2, and so on.

To get the most out of this new approach, we need to make two more improvements. We need to change core so that the exact same module can work with Drupal 8 and 9 if the module developer uses the latest APIs. We also need to provide full data migration from Drupal 6, 7 and 8 to any future release. So long as we make these changes before Drupal 9 and contributed or custom modules take advantage of the latest Drupal 8 APIs, up-to-date sites and modules may just begin using 9.0.0 the day it is is released.

What does this mean for Drupal 7 users?

If you are one of the more than a million sites successfully running on Drupal 7, you might only have one more big upgrade ahead of you.

If you are planning to migrate directly from Drupal 7 to Drupal 9, you should reconsider that approach. In this new model, it might be more beneficial to upgrade to Drupal 8. Once you’ve migrated your site to Drupal 8, subsequent upgrades will be much simpler.

We have more work to do to complete the Drupal 7 to Drupal 8 data migration, but the first Drupal 8 minor release that fully supports it could be 8.4.0, scheduled to be released in October 2017.

What does this mean for Drupal developers?

If you are a module or theme developer, you can continually update to the latest APIs each minor release. Avoid using deprecated code and your module will be compatible with Drupal 9 the day Drupal 9 is released. We have plans to make it easy for developers to identify and update deprecated code.

What does this mean for Drupal core contributors?

If you are a Drupal core contributor and want to introduce new improvements in Drupal core, Drupal 8 is the place to do it! With backwards compatibility layers, even pretty big changes are possible in Drupal 8.

When will Drupal 9 will be released?

We don't know yet, but it shouldn't matter as much either. Innovative Drupal 8 releases will go out on schedule every six months and upgrading to Drupal 9 should become easy. I don't believe we will release Drupal 9 any time soon; we have plenty of features in the works for Drupal 8. Once we know more, we'll follow up with more details.

Thank you

Special thanks to Alex Bronstein, Alex Pott, Gábor Hojtsy, Nathaniel Catchpole and Jess (xjm) for their contributions to this post.

DrupalCon Baltimore: Learn how to delight your customers

Drupal - Mon, 03/13/2017 - 07:24

Join us at DrupalCon Baltimore from April 24-28 for a week of inspiration, networking, and learning. Meet Drupal experts and industry leaders who will share new ways to create digital experiences that delight customers, citizens, students, patients, and more.

The event offers programming for decision makers (CIO/Director) as well as digital teams (developers, project managers, site builders, content strategists). Be sure to check out these suggested sessions for both audiences.

Top Five Reasons To Attend DrupalCon
  • Get inspired! Hear Dries Buytaert’s vision for digital transformation and Drupal.
  • Network with peers at 4 industry summits and case study sessions on Bluecross Blueshield, Cornell University, Mass.gov, NBA, Quicken, YMCA, and more.
  • Level up your team's skill with 10 trainings and 161 sessions taught by Drupal masters.
  • Find solution partners. Visit the exhibit hall to meet Drupal’s robust vendor ecosystem.
  • Be Amazed. Meet the open source community that powers Drupal.

Register today. Prices increase March 24th. Attendees can come for the week or just for a day. Plus, the Baltimore Convention Center is easy to reach - just 30 minutes from Baltimore Washington Airport and 15 minutes from the Amtrak Station.

We look forward to seeing you at DrupalCon Baltimore!

What’s new on Drupal.org? - February 2017

Drupal - Thu, 03/09/2017 - 08:17

Read our Roadmap to understand how this work falls into priorities set by the Drupal Association with direction and collaboration from the Board and community.

Drupal.org updates Industry Pages Launched

After a great deal of preparation, user research, and content development we've launched the first three 'Drupal in your Industry' pages. These first three pages highlight the power of Drupal in Media and Publishing, Higher Education, and Government. Each of these pages uses geo-targeted content to reach audiences in: the Americas; Europe, the Middle East, and Africa; and the Asia Pacific, Australia and New Zealand regions.

These pages are targeted at evaluators of Drupal in these specific industries. From our research, we've found that these evaluators typically have Drupal on their short list of technology choices, but are not familiar with how a complete solution is built on Drupal, and they're eager to see success stories from their industry peers.

We'll be expanding on this initiative with additional industry pages as time goes on.

Project Application Revamp

In February we completed phases 1 and 2 of the Project Application Process Revamp. This has meant polishing up the security advisory coverage messages that are provided on project pages, adding a new field for vetted users to opt-in to advisory coverage for their projects, and adding security advisory coverage information to the updates xml served from Drupal.org. With these issues complete we'll be able to move forward with Phase 3 (opening the project promotion gates) and Phase 4 (improving code quality signals and incentivizing peer review) as we roll into March.

[Author's note] The project application revamp hit a major milestone in early March with the completion of Phase 3. Now, any user who has accepted the git terms of service may now promote sandbox projects to full projects with releases, and the application process has been re-purposed for vetting users who want the ability to opt into security advisory coverage for their projects. Look for more information in our upcoming March post.

2017 Community Elections are Live

On February 1 we opened self-nominations for one of the two community-at-large seats on the Drupal Association Board of Directors. At the time of this post, self-nominations have closed and now it's time to vote!.

Each year we make incremental improvements to the elections process. This year we've allowed each candidate to present a short 'statement of candidacy' video - and we've updated the ballot to allow easy drag-and-drop ranking of candidates.

Voting closes on March 18th, so make sure to vote soon!

Documentation polish, and new "call-out" templates

As the migration of content into the new documentation system continues, we've continued to polish and improve the tools. In February we made a few small improvements including: help text for maintainers and fixes for links to the discuss page in email notifications. We also made one large improvement: Call-out templates for highlighting warning information or version-specific notes within a documentation page. These templates are available using the CKEditor Templates button when editing any documentation page.

The documentation editor may select from the 'Warning note' template, which will highlight cautionary information in a visually distinct orange section on the page, or the 'Version-specific note' template, which allows users to highlight information that may only be relevant to a specific minor release of Drupal.

Here are two examples of what the call-outs will look like to a documentation reader.

DrupalCI Coding standards testing

DrupalCI continues to accelerate the pace of Drupal development as we make the system more efficient and add new features. In February we enhanced the coding standards testing that was added DrupalCI in January. Using PHPCodeSniffer, ESlint, and CSSlint coding standards results are available in the test results' Build Artifacts directory, including automatically generated patches to fix found issues. We've also begun displaying summary information about coding standards testing on Drupal.org test results. Again we'd like to thank community contributor mile23 for his work on this feature.

More useful error output

We also made DrupalCI's error output more detailed, to make it more immediately clear to developers what the issue with a particular patch might be. Developers will now see messages on the test result bubbles, for example a 'patch failed to apply' error rather than a generic 'CI error' message.

Community Initiatives Contrib Documentation Migration

We want to continue to encourage Project maintainers to create documentation guides on their projects using the new documentation content types. Maintainers can then migrate their old documentation content into these new guides, or create new documentation pages. For more information about this process, please consult our guide to contrib documentation.

Help port Dreditor features to Drupal.org

Are you a Drupal.org power user who relies on Dreditor? Markcarver is currently leading the charge to port Dreditor features to Drupal.org, and invites anyone interested in contributing to join him in #dreditor on freenode IRC or the Dreditor GitHub.

Infrastructure Special note: Drupal Association seeks Infrastructure Services vendor

We'd also like to announce a Request for Information. The Drupal Association seeks an infrastructure services vendor to help us manage the underlying infrastructure that supports Drupal.org, our sub-sites, and the services we maintain. Our internal engineering team will continue to manage the sites and services themselves, while this vendor will help us with systems administration, virtual machine management, monitoring and pager responsibilities, disaster recovery, etc.

For more details about this request for information, please see our post on the Association blog.

———

As always, we’d like to say thanks to all the volunteers who work with us, and to the Drupal Association Supporters, who made it possible for us to work on these projects. If you would like to support our work as an individual or an organization, consider becoming a member of the Drupal Association. Follow us on Twitter for regular updates: @drupal_org, @drupal_infra

The full circle of Drupal adoption

Drupal - Tue, 03/07/2017 - 16:04

The Engineering Team provides support to many community members and everyone at the Association. Every day, the team helps people who are at different stages of the Drupal adoption journey. As part of our membership campaign, we're taking a close look at how the team makes an impact throughout this cycle through the work to support a few different Association programs.

Industry Pages: convincing decision makers to adopt Drupal

The team played a key role in the Industry Pages project—from conception to execution. The industry pages help decision makers see how Drupal achieves the vision Dries' set forth when he described Drupal as the platform for ambitious digital experiences.

The first three industry pages for media and publishing, higher education, and government are now on Drupal.org. These pages tell stories of success with Drupal for three verticals with geo-targeted content to show our global audience the solutions that are most meaningful to them. We plan to learn from this project and to expand into new verticals. By highlighting what Drupal can do for you, and connecting decision makers to service providers and industry peers, the industry pages are a powerful tool for leading the way to wider adoption.

Drupal Jobs: wider adoption leads to more career opportunities

The team is responsible for Drupal Jobs, the subsite dedicated to helping employers and job seekers connect for Drupal-related opportunities. Ever since Drupal Jobs launched in 2015, it has helped increase awareness of the Drupal project. As the pool of employers grows, so do the career opportunities. When more Drupal jobs are available, our ecosystem grows. Wider Drupal adoption becomes possible.

DrupalCon: Events site brings us full circle

DrupalCon unites our global community and people who want to know more about the project. On the Events site, the engineering team supports everyone—event organizers who post content, speakers who submit sessions, and attendees who register using Drupal Commerce and CoD. With a great UX on con sites and fun theme implementation, we show users what Drupal can do for you.

Around we go, thanks for coming along

As the adoption journey goes full circle and we see these efforts continue to help maintain and grow a strong ecosystem, we appreciate that you are coming along with us. To help sustain the work of the Drupal Association, join as a member. Thank you!

It's Time To Vote - Community Elections

Drupal - Mon, 03/06/2017 - 14:55

Voting is now open for the 2017 At-Large Board positions for the Drupal Association!  If you haven't yet, check out the candidate profiles including their short videos found on the profile pages. Get to know your candidates, and then get ready vote.

Cast Your Vote!

How does voting work? Voting is open to all individuals who have a Drupal.org account by the time nominations open and who have logged in at least once in the past year.

To vote, you will rank candidates in order of your preference (1st, 2nd, 3rd, etc.). The results will be calculated using an "instant runoff" method. For an accessible explanation of how instant runoff vote tabulation works, see videos linked in this discussion.

Elections will be held from 6 March, 2017 through 18 March, 2017. During this period, you can review and comment on the candidate profiles.

Have questions? Please contact me: Megan Sanicki

Saving time and money for the Drupal community

Drupal - Thu, 03/02/2017 - 15:20

As you know, we've been highlighting the work of the Drupal Association Engineering Team during our membership campaign. Every day, this small team moves the needle forward so that we all have a better experience as users of Drupal.org. In this post, we explore how the team's recent work results in faster, less expensive Drupal development.  

Helping Drupal development move faster with DrupalCI

DrupalCI testbots are the next generation of testing infrastructure for Drupal.org, funded by the Drupal Association and maintained by the Engineering team. For any project on the site, DrupalCI testing can be enabled from the Automated Testing link on the Project page. Every time a contribution to the Drupal project needs to be tested, DrupalCI spins up a testbot on AWS to test those changes. The DrupalCI testbots are helping Drupal contributors to test patches faster than ever before and they are more cost effective than our last generation testbots, both in price-per-test and in expense to maintain.

In recent months, we've added a number of new features including:

We're proud to say that our work on DrupalCI has increased the speed of Drupal development, saving time and money!

We'd also like to thank the volunteers who've helped us to bring this project to life: Mile23, jthorson, nick_schuch, dasrecht, ricardoamaro, mikey_p, chx, shyamala, webchick, and jhedstrom.

Want to keep up with the engineering team? Subscribe to change notifications so you can see ongoing improvements.

Making the greatest impact with member and donor funds with a leaner Drupal.org

Drupal.org is more portable and maintainable because of updates in 2016 that streamline our infrastructure. We've virtualized the majority of the infrastructure and standardized on Debian 8 images. We've also updated our configuration and user management from Puppet 3 + LDAP to Puppet 4 + Hiera. Dev sites are more robust and we can create staging and development environments faster than before.

All of this makes Drupal.org more cost-effective to run, easier to maintain, and increases our development velocity when we're working on new features to support the community. These efficiencies help to conserve membership and donor funds for other programs to help the Drupal community, like fiscal sponsorship for camps, and Community Cultivation Grants.

Improving developers' lives by supporting Composer workflows for Drupal

Composer is the defacto standard for managing dependencies in the PHP world. Over the course of 2016, the Drupal Association Engineering Team developed Composer endpoints for Drupal allowing Drupal developers to use Composer to manage dependencies, and allowing PHP developers at large to manage Drupal as part of their larger PHP projects in this standard workflow.

Composer is a force multiplier for enterprise site owners and developers within the Drupal community and at large. By supporting Composer, we've further opened Drupal to the wider PHP community, thus bringing new people into the fold to contribute.

A big thanks to everyone who helped with Composer: seldeak - the creator of Composer and Packagist.org, webflo - the creator and maintainer of http://packagist.drupal-composer.org, timmillwood, dixon_, badjava, cweagans, tstoeckler, mile23, and also Appnovation, who sponsored the initial development of Drupal.org's composer endpoints.

A more secure home for the Drupal community

Keeping Drupal.org secure is also the responsibility of the Drupal Association Engineering Team (though we rely on some trusted volunteers to help - thanks, mlhess and basic!). From heartbleed, to dirtycow, to cloudbleed - the team is always ready to respond when a vulnerability is disclosed. But the team is not just reactive - they also take proactive steps to keep Drupal.org and all our users' data safe. From ensuring that most of our servers are only available to each other on a back-end network, to putting in protections against DDOS attacks, to building anti-spam tools to prevent bad actors from registering accounts on the site- the Engineering Team is looking to prevent problems before they happen.

We'll keep at it, with your support

Every day, we're on call to keep Drupal.org running and improving. The list of small changes we make to have a big impact on your Drupal.org experience grows by the day. You can help sustain the work of the Drupal Association by joining as a member. Thank you!

Drupal 8.3.0-rc1 is available for testing

Drupal - Wed, 03/01/2017 - 08:50

The first release candidate for the upcoming Drupal 8.3.0 release is now available for testing. Drupal 8.3.0 is expected to be released April 5.

Download Drupal-8.3.0-rc1

8.3.x includes new experimental modules for workflows, layout discovery and field layouts; raises stability of the BigPipe module to stable and the Migrate module to beta; and includes several REST, content moderation, authoring experience, performance, and testing improvements among other things. You can read a detailed list of improvements in the announcements of alpha1 and beta1.

What does this mean to me? For Drupal 8 site owners

The final bugfix release of 8.2.x has been released. A final security release window for 8.2.x is scheduled for March 15, but 8.2.x will receive no further releases following 8.3.0, and sites should prepare to update from 8.2.x to 8.3.x in order to continue getting bug and security fixes. Use update.php to update your 8.2.x sites to the 8.3.x series, just as you would to update from (e.g.) 8.2.4 to 8.2.5. You can use this release candidate to test the update. (Always back up your data before updating sites, and do not test updates in production.)

For module and theme authors

Drupal 8.3.x is backwards-compatible with 8.2.x. However, it does include internal API changes and API changes to experimental modules, so some minor updates may be required. Review the change records for 8.3.x, and test modules and themes with the release candidate now.

For translators

Some text changes were made since Drupal 8.2.0. Localize.drupal.org automatically offers these new and modified strings for translation. Strings are frozen with the release candidate, so translators can now update translations.

For core developers

All outstanding issues filed against 8.2.x were automatically migrated to 8.3.x. Future bug reports should be targeted against the 8.3.x branch. 8.4.x will remain open for new development during the 8.3.x release candidate phase. For more information, see the release candidate phase announcement.

Your bug reports help make Drupal better!

Release candidates are a chance to identify bugs for the upcoming release, so help us by searching the issue queue for any bugs you find, and filing a new issue if your bug has not been reported yet.

Pages