Planet Drupal

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 17 hours 12 min ago

Dries Buytaert: Evolving Acquia.com

Thu, 12/21/2017 - 13:21

At Acquia, our mission is to deliver "the universal platform for the greatest digital experiences" and we want to lead by example. This year, Acquia's marketing team has been working hard to redesign Acquia.com. We launched the new Acquia.com last week. The new site is not only intuitive and engaging, but "practices what we preach", so to speak.

Over the course of our first decade, Acquia's website has seen a few iterations:

The new site places a greater emphasis on taking advantage of our own products. We wanted to show (not tell) the power of the Acquia Platform. For example, Acquia Lift delivers visitors personalized content throughout the site. It was also important to take advantage of Acquia's own resources and partner ecosystem. We worked in partnership with digital agency, HUGE, to create the new design and navigation.

In the spirit of sharing, the marketing team documented their challenges and insights along the way, and reported on everything from content migration to agile development.

The new site represents a bolder and more innovative Acquia, aligned with the evolution of our product strategy. The launch of our new site is a great way to round out a busy and transformative 2017. I'm also very happy to finally see Acquia.com on Drupal 8! Congratulations to every Acquian who helped make this project a success. Check out it out at https://www.acquia.com!

Freelock : Another Wednesday, another round of security updates

Thu, 12/21/2017 - 01:10
back_door.jpeg

Drupal security updates generally come out on Wednesdays, to try to streamline everybody's time. WordPress security notices come out... well, whenever whichever feed you subscribe to bothers to announce something.

Today's notices showed some striking differences between the two communities.

maintenanceSecurityWordPressDrupalDrupal Planet

myDropWizard.com: Drupal 6 version of 'me aliases' module not affected by SA-CONTRIB-2017-097

Wed, 12/20/2017 - 20:31

Today, there was a Highly Critical security advisory for a Remote Code Execution (RCE) vulnerability in the me aliases module for Drupal 7:

me aliases - Highly critical - Arbitrary code execution - SA-CONTRIB-2017-097

This module provides shortcut paths to current user's pages, eg user/me, blog/me, user/me/edit, tracker/me etc.

It was incorrectly handling URL arguments that could allow an attacker to execute arbitrary PHP code.

However, the way the Drupal 6 version of the module handles URL arguments isn't vulnerable in the same way. So, Drupal 6 users can rest easy - your site isn't affected by this issue.

But if you do use it on Drupal 7, given the criticality of this issue, please update right away!

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Drupal.org blog: Developer Tools Initiative - Part 4: What's next?

Wed, 12/20/2017 - 18:39

This is the fourth post in our series about integrating Drupal.org with a 3rd party developer tooling provider:

With our plan to create modular integration points for our tooling options, we have a few clear steps for moving forward:

Phase 1: Prep work
  • Deprecation of password authentication for Git, since many external tooling services no longer support it.
  • Working with core to provide compatibility for semver versioning for contrib, both because this is needed for Composer, and because all of the third party developer toolsets we are considering have begun to standardize on semver.
Phase 2: Initial implementation, replacing current features
  • Replacement of custom, bespoke Twisted Git daemon with standard BitBucket repositories.
  • Replacement of unmaintained CGit with supported BitBucket code viewing.
Phase 3: New features
  • Integration of merge request 'hook' into issue queues, to allow contributors to use a pull request workflow instead of patches.
    • Modular - to be used with BitBucket for now, but potentially another solution when more mature.
  • Integration of code review 'hook' into issue queues, to give us powerful inline code commenting tools.
    • Modular - to be used with BitBucket for now, but potentially another solution when more mature.
Phase 4: Implement Hybrid Integrations for other toolsets
  • Updating project page integrations such that those projects which are already hosted on third party tools such as GitHub or GitLab (for example, Drush) can easily login with SSO, synchronize their repositories, and choose the canonical home of their issues.
On-going: Evaluation
  • Re-evaluate other tooling solutions as blocking issues are resolved and their feature-sets evolve.
So that's the update!

In short: after more than a year's evaluation of the current leaders in open source tooling solutions, including direct collaboration with several of those teams, we are going to focus on making Drupal.org modular to integrate with the best tooling solution as it develops. For now, we will be implementing key improvements for Drupal developers using BitBucket for our repository hosting, code viewing/review, inline editing, and merge requests - integrated with the existing project pages and issue queues.

We'd like to thank the following people for their involvement in this initiative at various times through the process:

Drupal Association Staff

The Technical Advisory Committee (TAC)

Members of the community

Drupal.org blog: Developer Tools Initiative - Part 3: Illustrating modular integration for Developer Tooling on Drupal.org

Wed, 12/20/2017 - 18:37

This is the third post in our series about integrating Drupal.org with a 3rd party developer tooling provider:

Below are some rough mockups of what a modular integration between Drupal.org's issue queues and a third party toolset could look like. For the sake of this example, I've used BitBucket as the tooling provider, as that is likely to be our interim toolset for the reasons outlined above. However, one can easily imagine these functions being substituted for their equivalents in other toolsets.

The following is only an early concept. These are by no means final designs for each of these integration points, but they will help to visualize how these tools will be integrated with Drupal.org.

Mockup: Workspaces in the issue summary

The biggest change for contributors would be the addition of a new place in the issue summary to contain these workspaces. For most issues we anticipate a single workspace, as most issues are resolved via collaboration on a single code path, however we would be able to generate multiple workspaces per issue for multiple solutions being proposed in parallel:

The key functions of the Proposed code workspace are: the ability to make a new workspace, the ability to clone an existing workspace, the ability to create/view/edit a workspace merge request. The latest test result and ad-hoc testing options for each workspace would be provided here as well.

Mockup: Propose new Code

The "Propose new code" button is very simply a way to automatically generate a new workspace. This would only be used when a contributor wants to propose an alternate solution to whatever is currently under development. When pressed, we would generate a new workspace with the back-end tooling provider (whether as a fork, branch, or Git namespace) and add it to the table to be cloned, viewed for comments/inline editing, or ultimately to create a new merge request.

The new workspace will be generated with a name based on the issue id, and will present its own test result, clone, and merge request features.

If a user wants to collaborate on an existing solution instead, they can simply clone that workspace locally, or view it to make inline edits. Because some issues can languish for months, or even years, we also want to automate the process of rebasing these workspaces from their parents.

Mockup: Automatic comments as workspaces are updated

Whenever a change is made within the third party toolset, we would use the API to call back to Drupal.org and leave a system message describing the change, as well as linking to the relevant part of the third party toolset UI.

This is what an automated issue comment for code review might look like:

This is what a comment for recently pushed changes would look like:

And this is what a comment for inline edits could look like:

Mockup: Clone

The clone button would simply provide a basic modal pop-up with instructions for collaborators to clone the workspace locally with Git. This is not the final url pattern (one of our goals is to avoid changes in canonical git urls where possible) but it could look something like this:

$ git clone ssh://git@bb.drupalcode.org/is/drupal.git

Mockup: Create Merge Request (in BitBucket)

Merge requests allow contributors to propose changes to projects they don't maintain, and provide maintainers an easy way to view proposed changes.

The create merge request button would allow the user to view the current workspace and request that it be merged into the canonical parent. Only a project maintainer would have the permissions to complete the merge.

Code in a workspace with an open pull request can continue to be iterated on by the contributors. Code comments, diffs, and reviews are summarized on the request.

Mockup: View Merge Request (in BitBucket)

View merge request, like 'create merge request' would allow any collaborator to view the current workspace. This could also be used to initiate inline code edits, or leave code comments.

Mockup: Inline editing

Inline editing allows a quick and easy way for people to propose "standalone" changes to e.g. documentation, markup, etc. without having to have an entire development stack.

We would rely on the third party tooling provider's inline editing functionality. In the example below, we can see how an inline edit is made using BitBucket:

Mockup: Code review

As with inline editing, we would rely on the third-party tooling provider's tools for code review. In the example below you can see the code review options provided by BitBucket:

As indicated above, these mockups are simply an illustration of what this integration could look like, not final designs. However, this has hopefully shown how we can introduce a hybrid model to integrate the best features of a third party tooling provider (pull requests, code review, inline editing), while retaining the essential nature of the drupal-flow.

In our next post:

We outline our roadmap for this initiative.

Drupal.org blog: Developer Tools Initiative - Part 2: Comparing our options

Wed, 12/20/2017 - 18:33

This is the second post in our series about integrating Drupal.org with a 3rd party developer tooling provider:

In this update we'll talk about the specific options we've been evaluating to improve the tools for developers on Drupal.org. For each of these options we've built prototype workflows, stood up test integrations, and opened a dialogue with the creators of these toolsets about any gaps we identified. You'll see a summary of how each tooling option does or does not live up to the criteria we outlined in our last post.

Issue Workspaces

At DrupalCon Los Angeles in 2015, Mixologic from the DA Engineering team proposed the concept of Issue Workspaces. While we've historically talked about this idea as a single concept, it actually breaks down into two key components:

  1. The definition of a modern, idealized workflow for the Drupal project.
  2. A technical implementation using a bespoke tooling solution built on Git Namespaces to implement this workflow.

Criteria (for a bespoke implementation):

  • Familiar workflow.
    • ❌/ While an implementation of workspaces based on a bespoke git-namespaces implementation has several technical advantages, it will not appear nearly as familiar to outside developers as a more standard 'pull request' implementation. (Though it would be functionally very similar).
  • Preserve the most valuable parts of Drupal's workflow.
    • By implementing a bespoke solution we could exactly tailor the solution to the needs of the Drupal community.
    • ❌ However, the needs of that community are great, and our capacity to build a 100% bespoke solution that meets all the community's needs is not clear.
  • Leverage a partner who will keep evolving their code collaboration featureset.
    • ❌ Building issue workspaces using a bespoke git namespaces implementation would require us to continuously compete on features with major third party tooling providers that have much greater resources.

A purely bespoke implementation misses the mark on two of our three primary criteria. Fortunately, however, two years after the original proposal, it is no longer necessary to build a bespoke solution in order to implement an idealized workflow for the Drupal project. It is something that can be done by integrating the existing Drupal.org project pages and issue queues with third-party tooling solutions. Leveraging third party solutions provides several advantages including: familiarity to a wider audience of developers, a continually evolving featureset, and mitigation of the risks of maintaining a bespoke solution with a small team of engineers.

Here is the idealized 'Drupal-flow' visualized:

  • Every issue should be associated with one or more canonical workspaces (git repos+merge requests) which can be collaborated on by any contributor, and merged into the canonical parent by a project maintainer.
  • Contributors should be able to modify the code in these workspaces by:
    • Checking out the code and committing/pushing changes to the workspace.
    • Inline editing files within a workspace.
    • Legacy: uploading a patch.
    • Any contribution method should trigger the appropriate tests.
  • Workspaces should be rebased (manually or automatically) on any changes to the canonical parent.

This workflow is not dissimilar to the default GitHub flow, GitLab flow, or even the suggested BitBucket flow. These are all variations of the generic concept of 'Git flow' created by Vincent Driessen. However, the important difference comes in how each of these solutions tries to integrate a gitflow model into their issue/pull-request model.

The dominant model of these large third party tooling providers is not particularly collaborative. It encourages forks-of-forks, separates conversation about potential solutions onto multiple branch comments or merge requests threads, and generally caters to single developers working on individual proposed solutions, with one ultimately selected by the maintainer and the rest thrown away.

This is a key area in which the 'Drupal-flow' differs from the standard workflow that is implicitly enforced by these toolsets. Our ethos encourages collaboration of many developers on a single solution, and a single threaded conversation.

The gitflow behind the scenes may be identical, but the user experience wrapped around that flow makes very different assumptions about how people will collaborate.

GitHub

GitHub is of course the dominant player in the open-source tooling space. For many years though, their toolset was very much targeted at smaller open-source projects, and their default workflow highly encourages a many-to-many, forks-of-forks workflow, rather than the many-to-one single-threaded collaboration that is part of the Drupal community's ethos. More recently, GitHub has been improving their featureset, providing better issue management tools, more control over organization-level namespaces, and a new app marketplace that allows developers to extend GitHub's core featureset.

We reached out to GitHub and spoke with members of the technical and partnership teams, and while they were excited by the idea of bringing a project like Drupal to GitHub, we did run into some unresolvable blockers - most critically, by policy GitHub does not allow users of GitHub Enterprise to run their own public instances. This means we would have to migrate Drupal projects to GitHub.com, rather than self-hosting our instance.

Criteria:

  • Familiar workflow
    • ✔ GitHub is unquestionably the dominant platform for code collaboration on the web today.
  • Preserve the most valuable parts of Drupal's unique workflow
    • ❌ No way to enforce Drupal.org as the home of projects. While we can still keep project pages on Drupal.org there is nothing to encourage visitors who find the project on GitHub to treat the Drupal.org project page as canonical.
    • ❌ ;No way to enforce our workflow - forks of forks of forks of Drupal core into personal namespaces would be one click away.
    • ❌ Issue management tools are not setup for large, crowd-sourced teams.
      • Even for large community projects, it's more typical for only one or two developers to work on a single github issue at a time. Collaboration tends to be divided across issues, rather than within them.
    • Hard blocker Changing issue metadata requires maintainer permissions. (i.e: No way for non-maintainer collaborators to set an issue to RTBC)
    • ❌ Limited ability to manage project maintainers, especially in the case of abandoned or insecure projects.
  • Leverage a partner who will keep evolving their code collaboration featureset.

Other issues:

  • License/Source availability
    • ❌ GitHub is closed-source.
  • API availability
  • Hybrid integration
    • ✔ A hybrid integration between Drupal.org and GitHub is possible with SSO, automatic repository syncing, and a choice of using our issue queue or theirs.
    • ❌ However, there would be no portability of issues across a project that uses GitHub to one that does not.
    • ❌ Projects choosing to use the GitHub issues would not have access to DrupalCI
    • ⸗/❌ Projects using GitHub issues would not have access to contribution credit (though it may be possible to develop an app).
  • Data portability/vendor lock-in

    • ⸗/❌ GitHub's data migration feature is only available as part of GitHub enterprise.
    • ❌ GitHub policy will not allow us to self-host, which would allow us to work around some of the issues of preserving our Drupal-flow.
  • Developer support
    • ⸗ GitHub is well-funded and has a large team of developers improving the product. However, it is not open source, and so there is no capacity for the community to fill in the gaps on anything GitHub fails to provide.
    • ✔ GitHub has recently added a new 'apps' architecture, enabling deeper integration.
  • Maintainability for an engineering team of limited resources
    • ✔ Repositories hosted on GitHub would be easy to maintain, but we would have little access or control in the event of issues, and little ability to customize the workflow for the community's needs.
  • Cost
    • ✔ The GitHub team would be willing to provide the Drupal project an enterprise account.
  • Unintended consequences
    • ⸗/❌ Moving most of our developer traffic to hosted GitHub could have a significant impact on Drupal.org traffic, affecting everything from our search presence to revenue programs.

GitHub is a no-go.

GitLab

GitLab is the up-and-comer, and is becoming exceptionally popular in the open-source space - even beginning to be adopted by larger open source projects such as GNOME and Debian.

We've worked closely with the GitLab team as well. In contrast to GitHub, GitLab's terms would allow us to run our own instance of the service. GitLab's fundamental workflow is very much like GitHub's - a one-to-many model of forks of forks. After discussing our workflow with their engineers GitLab has begun implementing their new 'fork network' feature, allowing merge requests across forks. However, this doesn't quite achieve the goal of allowing our many-to-one collaboration model just yet.

GitLab is very close to being a good solution for an Open Source project of Drupal's scale, and the rate at which they are improving the service is impressive. GitLab is also already a favorite of many in our community for personal or professional projects. Given some more time, it may ultimately be able to tick all the boxes.

Criteria:

  • Familiar workflow
    • ✔ GitLab's workflow is very similar to GitHub's and it is the second most widely used code collaboration toolset.
  • Preserve the most valuable parts of Drupal's unique workflow
    • Hard Blocker - Maintainers cannot yet collaborate on downstream merge requests
    • ❌ Monolithic toolset - GitLab's featureset is designed to be used in an all or nothing way. There is no provision for using specific elements while disabling others.
      • For example, there is no way to disable GitLab project pages in order to keep the canonical project pages on Drupal.org.
    • No plugin architecture - changes must be accepted as merge requests upstream in GitLab, or re-rolled as patches with each release (aka, "hacking core").
      • No easy way to turn on or off elements of the GitLab UI.
      • No way to extend the GitLab featureset.
      • Very limited issue management states, and no ability to customize them.
  • Leverage a partner who will keep evolving their code collaboration featureset.
    • ✔GitLab's roll-out of new features is the fastest paced of the tooling providers that exist today.

Other issues:

  • License/Source availability
    • ⸗ / ✔GitLab Community Edition is open source, but GitLab Enterprise Edition (which we would need for a project of our scale and with our workflow needs) is not open source, only source-available.
  • API availability
    • ⸗ GitLab has a fairly robust api, but in our evaluation we found that many api features were undocumented, and others were deprecated without notification between minor versions.
  • Hybrid integration
    • ✔A hybrid integration between Drupal.org and GitLab is possible with SSO, automatic repository syncing, and a choice of using our issue queue or theirs.
    • ❌ However, there would be no portability of issues across a project that uses GitLab to one that does not.
    • ❌ Projects choosing to use the GitLab issues would not have DrupalCI integration, or issue credits.
  • Data portability/vendor lock-in
    • ⸗ GitLab's API and documented data model should make it possible to migrate our data to another system should it become necessary.
  • Developer support
    • ✔ As an open-source project, GitLab has a growing community of contributors, as well as the support of a venture funded mothership organization.
  • Maintainability for an engineering team of limited resources
    • Hard Blocker - GitLab's current file-handling makes full copies of a repository for every fork. Taking the number of open core issues as a representative example, Drupal.org would need a new 200 TB+ redundant storage apparatus, just to accommodate Core. GitLab needs to transition to a shared git-object model, or an alternative like git namespaces.
  • Cost
    • ✔ The GitLab team is willing to provide the Enterprise Edition to the Drupal community for free.
  • Unintended consequences
    • n/a

GitLab: not-yet.

BitBucket

BitBucket was the dark horse candidate. Atlassian products are well known in software development circles, but they are often more tolerated than beloved. However, when we sat down at Midwest Drupal Summit in August and looked at the options we explored so far and found them to be not quite baked - BitBucket began to show some advantages as a solution.

For one thing, BitBucket has recently put a heavy focus on user experience and collaboration features. It also has the most flexible permissions model for control over branch permissions, forking, and automatic rebasing of any of the toolsets we evaluated. Finally, it can be implemented modularly - allowing us to use the components that serve our workflow and disable the ones that don't.

Criteria:

  • ✔/⸗ Familiar workflow
    • BitBucket implements a very standard pull request workflow. It is not as widely popular as GitHub or GitLab, but should be easily learned by developers familiar with either of those systems.
  • ✔ Preserve the most valuable parts of Drupal's unique workflow
    • Of all the options we prototyped, BitBucket is the only one which provides the flexibility needed to preserve key elements of our workflow - in particular the ability to cleanly use only the parts of BitBucket that we need (specifically, merge requests, inline editing, and code commenting) without having to use issues or project pages that are less sophisticated than our existing solutions.
  • ✔ Leverage a partner who will keep evolving their code collaboration featureset.
    • Though it's flown under the radar, Atlassian has been making some significant improvements to BitBucket from a feature and user experience point of view over the course of the past year.

Other issues:

  • License/Source availability
    • ⸗/❌ Bitbucket is not open-source, only source-available, though they have an open source licensing program.
  • API availability
  • Hybrid integration
    • ✔BitBucket is much more flexible in terms of choosing which features to use, and which to disable- allowing a fairly tight hybrid integration.
  • Data portability/vendor lock-in
    • ✔/ ⸗ BitBucket stores repositories as standard git objects on the file system, making it relatively straightforward in case of a future migration to another system.
  • Developer support
    • ⸗ BitBucket has the professional support of Atlassian, but does not have a robust open source community driving feature development.
  • Maintainability for an engineering team of limited resources
    • ✔ BitBucket is implemented with an api-first methodology, and is well documented, making it straightforward for a relatively small team to support a selective integration such as what we propose here.
  • Cost
  • Unintended consequences
    • n/a

BitBucket: the best tool in the current landscape given our community's needs.

To sum up, each of the toolsets we evaluated have advantages and disadvantages. However, if we want to move forward with making improvements for our developers TODAY, we have determined that the best way to do that is to create modular integration points, and use the toolset that currently meets our criteria: BitBucket. As these toolsets continue their rapid development, we will continue to periodically re-evaluate them.

In our next post:

An illustration of what the future of Drupal.org's developer tools could look like.

Drupal.org blog: An update on the Developer Tooling Initiative for Drupal.org - Part 1

Wed, 12/20/2017 - 18:20

The initiative to improve Drupal.org's developer tools is part of a broader effort to broaden the reach of Drupal, not just to end-users and evaluators, but to a wider audience of developers as well. Improvements to our tools are an opportunity to remove friction to changes, increase the quality of changes, improve velocity of changes, and make contributing to Drupal delightful.

The initiative began in coordination with Drupal Association Staff, the Technical Advisory Committee, and a small group of volunteers from the community. We first announced the initiative in October of 2016, and provided our last update at the end of April of this year. Since that time a great deal of work has been underway to evaluate and prototype our options, collaborate with the vendors who supply these toolsets, and make some decisions about the direction we want to move in, with more data in hand.

Buckle up! Because this is such a large topic we've broken it into multiple posts:

Want a TLDR?

Where do we stand now?

Drupal is one of the longest-running open source projects on the web, and for more than 15 years (and many more to come), Drupal.org has been the home of the project. Over the years, we've built a developer toolset to serve the unique needs of the project. These tools have evolved as the open source environment changed. Right now, we use a combination of best-of-breed third party technologies, such as Git, Jenkins, Fastly, OpsGenie, integrated with our own bespoke tools, including issue queues, project pages, etc.

Right now, some of the third party and bespoke tools that we are using are market leading, whereas others have fallen behind. For example, CGIT (third party) and the patch workflow (bespoke) have both fallen behind compared to toolsets that can be found on other tooling providers. On the other hand, our issue crediting system (bespoke) is market leading, and a model for other projects to follow.

In the end, we will always be negotiating a balance between what we can do uniquely well with bespoke solutions, and integrating the latest and greatest of third party solutions as they coalesce around best practices that we want to adopt as well.

At DrupalCon Vienna it was decided that the Technical Advisory Committee had fulfilled their threefold mandate:

  • Helping the technical leadership transition on the DA engineering team after the downsizing in summer of 2016.
  • Helping manage the prioritization and scope of work.
  • Making recommendations to the board and DA staff on key initiatives, such as the project application process changes, and the direction to take with our developer tools.

We want to thank Angie Byron, Steve Francia, and Moshe Weitzman for serving on the committee. From here, DA engineering staff will carry the torch, though we will continue to rely on the individuals who were part of the TAC and other volunteers for feedback and help from time to time as we move forward.

Our evaluation

The most recent phase of this initiative was an evaluation of the leading contenders for open source tooling providers that Drupal.org could integrate with. These options were GitHub and GitLab, and after setting out to develop prototypes for these options, we added BitBucket to the list as well. For each of these options we built MVP prototypes, either as integrations with Drupal.org development environments, or with private organizations/repositories. Finally, we wanted to compare these options to the bespoke Issue Workspaces solution that we had proposed several years ago.

The Criteria

For the Developer Tools initiative to be successful we have to understand the criteria for improvement. From a user requirements point of view, contrib and core developers are unique stakeholders with unique requirements. Ideally we want a solution that increases velocity for both types of users, without fundamentally sacrificing the needs of one or the other.

  • 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.
    • Many-to-one collaboration: that is to say, many developers collaborating on a single solution to a problem.
    • Issue workflow.
    • Picking up on long standing issues where other collaborators left off.
    • Contribution credit.
  • If possible, leverage an expert partner who will help keeping our tooling up to date as open source collaboration tools continue to evolve.

There are also some technical requirements that came out of our evaluation process.

  • Retention of our data/ability to migrate.
    • Where possible, retain existing Git remote urls for projects.
  • Maintainability for a small staff.
  • Project maintainer management: including abandoned project reassignment, fork control, security release management, etc.

In terms of features, we were looking for:

  • Merge/pull requests.
  • Code review.
  • Inline editing.
  • Branch permissioning to allow collaboration on merge/pull requests.
  • Administrative tools for managing project maintainership.
  • Project management tools that equal or exceed what we have with the issue queues.*
  • Extensibility, so that we can preserve areas where the Drupal project is a market leader, such as with our contribution credit system.

*Our tools for issues are very sophisticated on an individual issue level, however we are sorely lacking in tools for grouping and prioritizing sets of issues, ie: issue boards.

Finally, cost:

  • Given the care with which we must use our funding from the community, any option we consider must be cost neutral with the current cost of maintaining our tools.

It's difficult to condense the scope of our evaluation into a short blog series, but in the following posts we'll talk about how the options we considered measured up to these criteria, what implementing one of these options could look like for Drupal.org, and our suggested implementation roadmap.

In our next post:

Our tooling options, compared.

Platform.sh: A look back on 2017

Wed, 12/20/2017 - 18:07
A look back on 2017 Crell Wed, 12/20/2017 - 17:07 Blog

Time flies. It's been quite a year for Platform.sh as our product continues to improve. One of the great things about a managed services product is that it can continually improve without you even realizing it. The sign of a successful product feature is that it feels like it's always been there. Who can imagine life without it?

Let's take a look at what we've improved just in the last 12 months...

January opened with support for HTTP/2 on all projects. HTTP/2 changes the way browsers and servers communicate, making it faster, more streamlined, and better tailored to modern, asset-heavy web sites. HTTP/2 "just works" automatically as long as you're using a reasonably modern browser and HTTPS.

And as of April, you're using HTTPS. Courtesy of Let's Encrypt, you now get a free, automatic SSL certificate provisioned for every environment. No one should have to think about HTTPS in 2017. It's just a part of the package.

April also saw the launch of our tiered CDN for Platform.sh Enterprise. The Global CDN combines a flexible, high-feature CDN for dynamic pages with a low-cost, high-bandwidth CDN for static assets. That offers the best of both worlds for sites that want the best performance for the least cost.

We've also continued to expand our available services. We kicked off the year with support for persistent Redis as a key/value store rather than just as a cache server. March saw the addition of InfluxDB, a popular time-series data service for recording time-based data. In June, we added support for Memcached in case Redis doesn't do it for you.

We also beefed up the functionality of our existing services, adding support for multiple-core Solr configurations and multi-database MySQL configurations. We even now support regular expressions in the router for more fine-grained cookie control.

And of course we've kept up with the latest releases of your favorite languages, be that Python, Ruby, NodeJS, or perennial favorite PHP 7.2. We even added preliminary support for Go and Java, both of which are in beta now. (Interested in trying them out? Please reach out to us!)

August included support for arbitrary worker processes in their own container. That allows an application to easily spin up a background task to handle queue processing, image generation, or other out-of-band tasks with just a few lines of YAML with no impact on production responsiveness.

As of October, we've added health notification support for all projects. At the moment they only cover disk usage, but in time will expand to other health notices. (If you haven't configured them on your project yet we strongly recommend you do so.)

We're also closing out the year with new support for GitLab, as well as more flexible control over TLS and Client TLS, plus a few other changes that line us up for even bigger things in the year to come.

Last but not least, all of that goodness is available down under as of July with our new Sydney region for Platform.sh Professional.

And that's all been just this year! What do we have coming in 2018 to further redefine "modern hosting"?

You'll just have to join us in 2018 to find out...

Larry Garfield 29 Dec, 2017

Dries Buytaert: Clean CSS with Stylelint

Wed, 12/20/2017 - 16:29

Last night I was working on the album functionality for this website. CSS is not my strong suit, so I wanted to get some help from a CSS linter. A CSS lint tool parses your CSS code and flags signs of inefficiency, stylistic inconsistencies, and patterns that may be erroneous.

I tried Stylelint, an open source CSS linter written in JavaScript that is maintained as an npm package. It was quick and easy to install on my local development environment:

$ npm install -g stylelint stylelint-config-standard stylelint-no-browser-hacks

The -g attribute instructs npm to install the packages globally, the stylelint-config-standard is a standard configuration file (more about that in a second), and the stylelint-no-browser-hacks is an optional Stylelint plugin.

Stylelint has over 150 rules to catch invalid CSS syntax, duplicates, etc. What is interesting about Stylelint is that it is completely unopinionated; all the rules are disabled by default. Configuring all 150+ rules would be very time-consuming. Fortunately you can use the example stylelint-config-standard configuration file as a starting point. This configuration file is maintained as a separate npm package. Instead of having to configure all 150+ rules, you can start with the stylelint-config-standard configuration file and overwrite the standard configuration with your own configuration file. In my case, I created a configuration file called stylelint.js in my Drupal directory.

"use strict" module.exports = { "extends": "stylelint-config-standard", "plugins": [ "stylelint-no-browser-hacks/lib" ], "rules": { "block-closing-brace-newline-after": "always", "color-no-invalid-hex": true, "indentation": 2, "property-no-unknown": true, "plugin/no-browser-hacks": [true, { "browsers": [ "last 2 versions", "ie >=8" ] }], "max-empty-lines": 1, "value-keyword-case": "lower", "at-rule-empty-line-before": null, "rule-empty-line-before": null, }, }

As you can see, the configuration file is a JSON file. I've extended stylelint-config-standard and overwrote the indentation rule to be 2 spaces instead of tabs, for example.

To check your CSS file, you can run Stylelint from the command line:

$ stylelint --config stylelint.js --config-basedir /usr/local/lib/node_modules/ css/album.css

Stylelint will point out errors, automatically fix some stylistic violations, or highlight where your rules are violated. In my case it found an error that was easy to fix:

For fun, I googled "Stylelint Drupal" and found that Alex Pott has proposed adding a Stylelint configuration file to Drupal core. Seems useful to me!

Amazee Labs: Zurich Drupal Meetup January 2018

Wed, 12/20/2017 - 12:49
Zurich Drupal Meetup January 2018

Join us on January 18th for the first edition of the Zurich Drupal Meetup, where we will discuss the possible future of  React, GraphQL and Drupal at the Amazee Labs Zürich office.

Vijay Dubb Wed, 12/20/2017 - 12:49

In the Meetup, Amazee Group CTO and Partner, Michael Schmid, will lead our discussion and address the following issue:

The idea of a decoupled Frontend and Backend has been around for a couple of years. Some teams tried them out, but nobody was entirely satisfied with it. Too many problems arose during development; bad or non-existing accessibility, no support for crawlers and bots, changing APIs and expensive refactorings. Even the simple task of displaying a menu on the frontend was problematic.

All these concerns retained us at Amazee Labs from actually trying it. We avoided the use of decoupled systems. That is until a couple of months ago. In summer 2016, we were able to connect React with Drupal via GraphQL for the first time, and felt comfortable using it in a project. To increase the stakes we applied it in a multiple hundred-thousand dollar projects. We wouldn't be Amazee if we didn't! 

What came out is a completely decoupled system built on React that powers 12 individual websites with a single Drupal Backend connected through GraphQL. All of it is completely tested as part of a continuous deployment workflow, is hosted on Docker, has server-side rendering, and not a single line of content or menu on the frontend.

As one of the leading Drupal and React agencies, we always look towards the future. We would like to take the opportunity to plan community activities for 2018 and beyond. Here is a list of topics we are looking to address:

- Define overall goals for Drupal in Switzerland 2018
- Fix dates & contents for meetups for the Zurich Drupal Community
- Pre-discuss planning for the next Drupal Mountain Camp

Come for great talks, people and networking. Sign up here at meetup.com

 

Agiledrop.com Blog: AGILEDROP: Drive greater business value with deeper integrations

Wed, 12/20/2017 - 12:18
While the first blog post of the series covered the meaning of words ambitious and digital experiences both as singular and combined entities, and the second blog post was dedicated to channels of communication and interaction, I will now turn the attention over to the possibilities of integrations with Drupal.    How small is too small There is quite a substantial gap between what is characterized as for the enterprise and as for an ambitious digital experience. The latter is far broader. In more than one way. The most obvious being, as it is not just for the enterprise, you can also… READ MORE

Aegir Dispatch: Ægir Rules

Wed, 12/20/2017 - 01:00
Aegir faithfully runs a lot of tasks for us, but sometimes one can fail for various reasons. That could be as simple as a filled up disk or a remote Git server that’s unavailable. When you’re logged in, you can quickly see what’s going wrong. But with more and more automation, there are days when you’re not watching the Aegir dashboard of your server. It could run a Git pull task because someone committed new code for the site you’re hosting, or a Let’s Encrypt certificate is being renewed.

Promet Source: Drupalcamp Cebu 2017 Up Close

Tue, 12/19/2017 - 23:54
Another Drupalcamp event had just successfully ended in Cebu! Wait... Where is Cebu?

Acro Media: Video: How Drupal Delivers a True Omnichannel Experience

Tue, 12/19/2017 - 22:43

The term "omnichannel" has been around for a long time, but in a lot of cases it was just a buzzword.

We talk sometimes about omnichannel being online and in store, but in reality, it refers to all the channels that are available to your customers. That's call-in orders, customer service, catalog orders, integrations with other fulfillment partners like Amazon or eBay—those are all channels through which you sell products.

Omnichannel is about having all those channels work together. So if Joe buys something online, for instance, he should be able to return it to the physical store, and the customer service rep in the store should be able to see his updated account history, because everything should sync up.

In the early days, basic omnichannel really just meant that if the product showed on the website, it was also in the store. But these days, omnichannel is also about customizing the experience for each channel.

So if Joe is on the app, it should automatically pick his closest store. It should show him what aisle or section the item is located in and whether its in stock. On the other hand, if Joe is buying online, he doesn't care what aisle it's in, he just wants to know how long it will take to get the item shipped to him. So you have to tailor the experience to each type of channel, but the systems all need to mesh together.

What can you expect from the omnichannel experience from most platforms?

You will generally get rudimentary stock syncing. That means that whether you sell items online or in store, you will know how many you have and when you're out of stock. But even that has variations. Do you know your inventory status in real time? Every hour? Or does it only sync nightly? That can make a big difference.

With most platforms, you're not going to get features like the ability to inform the customer where the item is located in the store. Only a few retailers do that because it's very difficult and requires a lot of extra work. You need to know that data, for one thing. So even if the platform supports that, that doesn't mean that you actually track the precise location of every single product in your store.

What's different with Drupal?

With Drupal, syncing is simple because we can use the same platform for everything: we have a point of sale, we have a web platform, and we can automatically do pushes to different channels like Amazon and eBay. We have real-time stock and shipping.

Then we can add more customizations. We can allow for your customers to start an order online and finish it in store, for instance. Or if they go into the store and find it's not in stock, the clerk can put in an order—but instead of it getting shipped to the store and the customer having to come and pick it up, the clerk can simply turn it into an online order and have the item shipped to the customer. This is the kind of stuff we can mostly do out of the box, but there's usually a bit of customization work to make it a smooth flow.

What's the deal with add-ons?

Drupal is well set up for omnichannel, but keep in mind that there can be problems any time you integrate with other systems. Payment gateways are usually not a problem, but you can run into issues if you have to pass data to some warehouse fulfillment system and it can't provide real-time stock info back. So Drupal can keep track of stock, but if they knock over a pallet in the warehouse, or they get a new shipment but take a while to put it in, that can be slow to update. So the caveat here is that you can be let down by other parts of your system.

Chat with us

If you'd like to how Drupal Commerce fits into your omnichannel solution, give us a shout. We're here to help.

qed42.com: Art of writing template files - Drupal 8

Tue, 12/19/2017 - 21:49

When it comes to Drupal 8 theming layer, there is a lot Drupal 8 offers. Few concepts that come to mind while thinking of Drupal 8 theme layer include Renderable Array, Cacheabilty, Cache Context, Cache Tags, Twig and Preprocessors. Some of these are improvements of old concepts, while others are new introduction in Drupal 8. In this post, I'll share my experience on how to best utilise these concepts for a robust and performant frontend with Drupal 8.

To get best out of this post, you should be comfortable with:

  1. Drupal 8 #cache
  2. Twig Debug
  3. Preprocessor functions


We will focus on the following concepts:

Renderable array caching, walk through Drupal 8 caching power and Cache contexts

Drupal 8 comes with a lot of changes and almost all of us are even familiar with these changes. So, now it’s high time we start exploiting these to get best out of Drupal 8. It’s very important to understand how Drupal 8 caching works. Go through drupal.org documentation besides implementing the same once thoroughly on a vanilla Drupal instance. At the end have an answer to all these questions:

Drupal Association blog: Call for Proposals: DrupalCon Europe License

Tue, 12/19/2017 - 19:09

The Drupal Association’s mission is to unite the global open source community to help them build and promote Drupal. One of the most important ways that we advance our mission is through DrupalCon, Drupal’s flagship event.

At DrupalCon, community members with a technical, business, and marketing background come together to unite as a community, level up their Drupal skills, and contribute to the project. As a global event, DrupalCon breaks down walls between countries and the various personas who build, use and support Drupal, making it an accelerator of knowledge sharing, relationship building and contribution.

DrupalCon is ready to grow.  We need a model that allows the community to deliver DrupalCon globally. Our vision is to empower all regions to host DrupalCon, providing this experience to communities around the world.  As a first step, we are licensing DrupalCon to the European region.

We are excited to empower a new entity grounded in the European Drupal community to take this special event to the next level. The DrupalCon license initiative is an opportunity to re-imagine DrupalCon Europe to uniquely serve the Drupal community. The license is designed to allow for a new creative direction while enhancing Drupal’s mission, vision and values while maintaining the integrity of DrupalCon.

With the help of the DrupalCon Europe License Committee, we created a process for entities to apply for a DrupalCon Europe license by 30 March, 2018. We reviewed approaches used by other conference organizers, with particular attention to the key attributes that allow TED to scale its TEDx events. Then, we applied those learnings to our licensing process.

In short, we learned that TEDx scales because of clear “rules and tools” for the licensee (aka event organizer) and we aimed to provide the same level of guidance and support for the DrupalCon licensee. There are clear guidelines in the license agreement and the event rules and we will provide support in the form of knowledge transfer, tools, and advisory services. We also recognize that this is our first time creating such a program, so we encourage entities who are applying to contact us to discuss any areas of concern or question.

Below details how to submit a proposal for the DrupalCon license and the criteria that the Drupal Association will use to select the licensee.

We are grateful for the help of Bert Boerland, Baddy Breidert, Alex Burrows, Gabor Hojtsy, Janne Kalliola, Zsofi Major, and Stella Powers, who participated in the DrupalCon Europe License committee and contributed many hours and great insight into this process.

Table of Contents
  • Key Points
  • Who Can Apply For a DrupalCon License
  • Important Dates
  • What To Submit To Apply for a DrupalCon License
  • DrupalCon License Rules
  • Drupal Association Support
  • Decision Making Criteria
Key Points Who Can Apply For a DrupalCon License

To be eligible to apply for a DrupalCon license, you must meet the following criteria:

  • An entity grounded in the voice and needs of the Drupal community. This can include, but is not limited to:

    • A professional event company

    • A Drupal community group

    • A collective of Drupal businesses

    • A Drupal business

    • An event organizing company that demonstrates how they will work with the Drupal community

    • An entity where someone on the team has event experience

  • Able to accept funds as a business or nonprofit

  • Must have successfully produced an event that broke even or was profitable. Or, the team member with event experience has worked on an event that broke even or was profitable.

  • Must agree to abide by and enforce DrupalCon’s policies and rules.

Important Dates

Above is a timeline of important dates to know. The call for a DrupalCon license proposal is now open and it closes on 30 March, 2018. In mid to late April, applicants will be interviewed and a licensee will be selected by the Drupal Association in May 2018.

As early as July 2018, The Drupal Association will provide an onboarding workshop to the licensee, to begin knowledge sharing, and map out how best to support the event organizer leading up to and during DrupalCon.

What To Submit To Apply for a DrupalCon License

To apply for the DrupalCon license, please submit the following items by 30 March, 2018 to DrupalConEurope@association.drupal.org. Your application must include the items listed below in the following formats (presentation, spreadsheet, document).

  1. DrupalCon Business Plan. Submit a business plan with the following information:

    • Event location and dates.

    • Detailed event budget, structured as similarly as possible to the current DrupalCon budget format.

    • Budget assumptions. Clearly define the budget assumptions for expenses. Also, include forecasted ticket and sponsor revenue. Define your ticket pricing plan and your sponsor strategy (who you will sell to and how you will create value for sponsors). Additionally, explain how you will secure the cash flow for initial event investments like securing the venue.

    • Details about your event team. Who are the key people on your team, what roles will they play, and what is their event experience?

    • An overview of how you will ensure the event reflects the Drupal community's needs and culture and moves the project forward.

    • The event’s mission and vision, which should align with the Drupal Association’s mission and vision.

    • Target audience and target size. Which personas will your event attract and generally in what ratio? Please define your personas.

    • Event goals, strategies and objectives

    • What value will you bring to each persona and how?

    • Programming concept overview (which we know can change as you get further into planning). Please be sure to adhere to the programming rules.

      • Event duration

      • Provide a sample program and suggested tracks

      • Share your general concept for session selection

      • What is your plan to ensure conference diversity (attendees and speakers)

      • Tell us about some aspirational keynotes you would like to invite

  2. Drupal culture. Tell us how you define Drupal’s community spirit and culture and what it means to you.

  3. What’s your “why”. Tell us why you want to organize DrupalCon. Why should you be selected, and how will you maintain the Drupal community spirit.

  4. Your needs. As seen on page 4, the Drupal Association will support you with knowledge sharing, tools, and advisory services. What additional needs do you have?

  5. About your past events. Submit an overview of your past event that you, your event partner, or your team member worked on. Describe the event audience, audience size, goals, and how you achieved those goals along with the event’s financial statements.

The Drupal Association will select the organizer who can demonstrate the best approach for creating value to a technical and non technical audience by uniting the community, leveling up Drupal skill, and accelerating the project through a sustainable model.

DrupalCon License Rules

The DrupalCon license is designed to encourage creativity, to re-imagine the event. That means you can decide what is the best programming to meet the attendee’s needs. Or you can decide that sustainability is best achieved by starting with a smaller event that grows over time. However, all proposals and the actual event must conform to the DrupalCon licensing rules and agreement to maintain the Drupal Association’s community and governance expectations, as well as DrupalCon’s brand experience.

You can find DrupalCon Rules here.  

You can find the DrupalCon license agreement here.

Since this is the first time the Drupal Association has crafted DrupalCon license rules, we are open to discussion. Please contact us if you feel a rule is a blocker to you submitting a proposal. If discussions result in a rule change, we will update the rules document to reflect that change.

Drupal Association Support

The Drupal Association wants to make sure the chosen event organizer is set up for success. We recognize this means that we will play a role leading up to and perhaps during the event. Here are some ways the Drupal Association will help. We are open to hearing about additional ways in which we might help.

  • In-person workshop: The Drupal Association staff will fly to the organizer’s location to run a workshop where we will do a knowledge transfer, training, and determine how the Drupal Association will play a support role during the event production phase.

  • Playbooks, Guidelines, and Templates. The Drupal Association has several production playbooks that we will share so the organizer can see how the event was produced in the past. We recognize that the event organizer may want to alter our approach or create a brand new one.

  • Advisory Services. You may have questions along the way and we are here to help. No question will be too big or too small. We can set up periodic check in meetings to provide guidance as you develop your event.

  • Access to tools. DrupalCon promotion and management relies on several tools that we will share with the event organizer including the DrupalCon event site, social media handles, access to DrupalCon email lists, etc.

  • Promotion Support

    • The Drupal Association can amplify your call for ticket sales, sponsorship, and content through our channels including social media, email, newsletters.

Decision Making Criteria

When reviewing and comparing proposals, The Drupal Association will select the event organizer by using the following criteria:

Category

Topic

Weight

Sustainability

Conservative, realistic, complete budget plan with clear revenue and expense budget assumptions

10

Staffing plan

Clearly defined leadership team description and a staffing plan for producing the event that is designed to avoid burnout

8

Goals, strategies, objectives

Clearly articulated goals, strategies, and objectives that move the project forward, serve multiple personas, and has achievable metrics.

9

Location

Easy to reach by European community

8

Event Dates

Avoids major holidays (national, religious, etc) and aligns with Dries Buytaert’s availability

10

Target Audience

Program serves multiple personas

8

Programming

Creative approach for serving all persona  while meeting the licensing rules.

9

Session Selection

Well thought out approach that adheres to the DrupalCon licensing rules.

7

Diversity & Inclusion

Well thought out approach for growing speaker and attendee diversity to exceed the DrupalCon Vienna benchmark

8

Definition of spirit/ culture

Strong understanding of the Drupal culture

7

Keynote examples

Creative, inspiring keynote ideas that speak to all personas

6

Event Planning Experience

Clear demonstration of event experience on the team

7

Acquia Developer Center Blog: A Look Inside Decoupled Architecture: The Engage Digital Application

Tue, 12/19/2017 - 18:07

“The most compelling advantage of API-first Drupal is not the way it negates Drupal's presentation features, it's the way it enables the capabilities of the CMS to power multiple applications and devices. Leveraging Drupal as a centralized data source enables authors to deliver content to multiple devices outside of Drupal, while leaning on the strength of the CMS editorial workflow and patterns.” -- Jason Enter, Manager Technical Services, Acquia.

Tags: acquia drupal planet

Jacob Rockowitz: Drupal 8 and the Webform module helps NYC online voter registration bill get passed

Tue, 12/19/2017 - 18:04

My family and I got to see Mayor Bill de Blasio sign the online voter registration bill into law which Ben Kallos, a New York City councilman and true fan of Open Source, sponsored. Kallos used the Webform module to demonstrate how easy it easy it is to capture a digital signature. The most ironic thing about watching the mayor sign the online voter registration bill, which is driven by the concept of digital signatures, into law, was the fact that he used used multiple pens to sign the bill. My daughter Lili and I both received pens that the mayor used to sign the bill. Everyone, myself included, has Kallos to thank for making this bill and experience happen. I guess - and this is a good thing - we’ll have to find other uses for our pens.

Last month, Kallos did a presentation at the NYC Drupal Meetup about how he used the Webform module to help get legislation passed to allow online voter registration for New Yorkers.

 

We all know that we can’t vote online yet, but I was surprised to realize that people can’t even register to vote online! Sure governments and municipalities move slowly, but how hard should it be to set up an online voter registration application? There is even an online HTML form that generates a filled-out PDF form that you have to print out, sign, and mail in. Next, someone manually re-enters your information, with no typos…duh. Kallos gets technology, which is why he sponsored this legislation and tackled the real challenge of showing his fellow council members how to capture a digital signature, which is essential for registering...Read More

Droptica: Droptica: Building a big website? Here are ten reasons why you should be using Drupal

Tue, 12/19/2017 - 12:24
When you’re building an advanced website, you can choose from among many technologies. Usually, the first choice is the programming language (PHP, Python, Java, ASP.NET, etc.) and then we decide whether we should code everything from scratch or use a framework to do all the heavy lifting. There is also a third choice, a more comprehensive solution –so-called CMF systems, which stands for content management framework. Drupal 8 is one of these systems. In this article, I will tell you why it’s worth it to choose Drupal as the basis for any large and advanced website.  By large and advanced, I mean one that is changed frequently. Content changes are carried out by at least one editor, supported by at least one developer (along with a QA tester and a sysadmin), who’s responsible for continuous development of the website, adding new functionalities, fixing the emerging bugs and so on.  Some examples of large and advanced websites:

Amazee Labs: Client Interactions - Amazee Agile Agency Survey Results - Part 8

Tue, 12/19/2017 - 12:24
Client Interactions - Amazee Agile Agency Survey Results - Part 8

This is part eight of our series processing the results of the Amazee Agile Agency Survey. Previously I wrote about estimations, this time let’s focus on client interactions. How regularly does the team meet the client and how is communication between the team and the client handled?

Josef Dabernig Tue, 12/19/2017 - 12:24 Client Meetings

When asked about “how regularly does the team meet the client”, 33% mentioned “more or once per week”, 30% selected they would meet “less frequently” compared to the 16.7% which chose “every two weeks”. This is followed by 6.7% that chose to meet clients “each day for the daily standup”, and the same amount chose to meet clients “never”. It looks like there is no apparent tendency but half of the teams choose to work together with clients more regularly, and another half of the team doesn’t have much client interactions.

For us, at Amazee this depends heavily on the project and the teams. In some cases we form teams together with clients where all developers will be assigned to the project full time in that consequence have regular client interactions. For the stable Scrum teams in Zurich that I work most with, we run multiple projects at the same time and therefore didn’t consider inviting clients to our daily meetings as we discuss several projects at the same time. As we have been successfully moving towards having fewer projects per team and a global maintenance team, we are considering this option though as to have closer client interactions between the team members. On top of that, we have found regular demos for clients and grooming meetings between the teams and clients beneficial. We balance the decision to do them based on how much money the client is willing to spend on having multiple people at a meeting.

Client Communication

In a second question, we asked “How is communication between the team and the client handled” and contestants could choose from a scale of 1-5. The lowest indicates communication is handled “exclusively by a person dedicated to talking to the client (PM, PO proxy, ...)”, and the highest, indicates that communication is handled “Always together with the entire team”. An equal share of 33% turned out to be with a 2 or a 3, 13.3% with a 1 or a 4 and 6.7% with a 5. We can see that there is a tendency to channel communication between clients and the team through a person within the company (PM, PO proxy).

For us at Amazee its a 2. Every project has a PO from our side assigned that will represent the client to the team if the client is not available and will represent the team to the client to have a single point of contact. Still, we encourage clients to meet the team regularly for a better understanding on both sides of the project and collaboration. The higher the ratio is that a team can dedicate their time to one project & customer, the easier it is to justify that the entire team will collaborate with the client. Being in an agency environment with multiple projects at the same time, those customers are not often to be encountered though. This is why we try to find a good compromise between customer collaboration with the team and efficiency gains of channelled communication.

How do you and your team interact with your clients? Please leave us a comment below. If you are interested in Agile Scrum training, don’t hesitate to contact us.

Stay tuned for the next post where we’ll look at agile practices.