Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 20 min 4 sec ago

Valuebound: How to send mail programmatically in Drupal 8

Tue, 15/03/2016 - 10:16

Sometime we require emails to be sent on certain events e.g. for a blog website or a news site we may need to send email after creating new article or blog or in case of e-commerce site we may need to send  confirmation mail after successful completion of an order. In this article we are going to explore how we can use Mail API in Drupal 8 programmatically for sending emails.
Here we will be looking on how to send the email after successful creation of article.

Sending email in Drupal is a two steps process:

  • Define your email properties (like subject, body, headers, etc.) in an appropriate hook_mail() implementation.
  • Use Mail manager to send email.


Step 1:

When we send an email programmatically, we need to…

Categories: Elsewhere

ActiveLAMP: Sandcamp 2016 Recap

Tue, 15/03/2016 - 03:00

The San Diego Drupal Camp was great! You can’t beat the weather in San Diego, and as usual, these regional events are great for catching up with old friends that are still plugging away with the Drupal content management system. Checkout our highlight video: This year I had the pleasure of giving 3 sessions at the camp, and as promised, I want to share the slides and code for everything that I presented. Each deck is iframed in on this article, feel free to checkout my github page</a< if you want the speaker notes too.

Read more...
Categories: Elsewhere

Drupal core announcements: Update: PHP dependencies removed from git (8.1.x and 8.2.x branches)

Tue, 15/03/2016 - 01:17

The Composer-managed vendor directory has been removed from the Drupal core git repository for the 8.1.x and 8.2.x branches. (This change was previously committed, but rolled back due to rate limits on Github affecting composer installation. Those limits have since been lifted, so we have recommitted the change.)

There will not be any changes for people downloading Drupal 8 from Drupal.org. The Drupal.org packager will add dependencies to zip and tar packages.

If you're not using zip / tar files, e.g. when using a git clone, run composer install to get dependencies. See https://www.drupal.org/documentation/install/download#git for instructions.

For background information, see the change record for this change and the related Drupal 8 core issue.

Categories: Elsewhere

Jeff Geerling's Blog: Happy #PiDay 2016 - Celebrating with the Raspberry Pi

Mon, 14/03/2016 - 22:53

I think today was my most Pi-full π day, ever! Let's see:

Early in the morning, I finished upgrading all the Ansible playbooks used by the Raspberry Pi Dramble so my cluster of five Raspberry Pis would run faster and better on the latest version of official Raspberry Pi OS, Raspbian Jessie.

Later, opensource.com published an article I wrote about using Raspberry Pis placed throughout my house to help my kids sleep better:

Raspberry Pi project to regulate room temperature and sleep better https://t.co/ikwRbS5wns by @geerlingguy pic.twitter.com/rXA1eWodIm

— Open Source Way (@opensourceway) March 14, 2016

Categories: Elsewhere

FFW Agency: Managing CSS and JavaScript files in Drupal 8 with Libraries

Mon, 14/03/2016 - 20:05
Managing CSS and JavaScript files in Drupal 8 with Libraries David Hernandez Mon, 03/14/2016 - 19:05

Drupal 8 revolutionizes the theming experience with many significant improvements to make theming easier, and give themers the flexibility and control they've never had before. One of those major improvements is to the library management system, which controls the attaching of CSS and JavaScript files.

In this post we will cover how to create and control libraries from a theme. This will include SMACSS categorization for CSS files, dependencies, how to conditionally attach libraries, manipulating libraries that come from anywhere in a site (core, modules, or base themes,) and targeting individual files for removal or replacement. All this without needing a single line of PHP.

Creating Libraries

The scripts and stylesheets properties used in previous versions of Drupal no longer exist. In Drupal 8 we manage all of these files using libraries defined in a .libraries.yml file, added to your theme.

Each library defined in this file includes a unique name, any number of CS or JS files, dependencies, and other information needed to define the properties of the library or assets.

Here is an example of a library file:

# In mythemename.libraries.yml

# Give your library a name.
my-library-name:
  version: "1.0.x"
  css:
    # The SMACSS category.
    base:
      # The path to the css file.
      assets/css/base.css: {}
    theme:
      assets/css/print.css: { media: print }
  js:
    assets/js/myglobal.js {}
  dependencies:
    - core/jquery

# In the following example, we add a Google font (Lato).
lato:
  css:
    base: '//fonts.googleapis.com/css?family=Lato': { external: true }

The file is in YAML format, which Drupal 8 uses for all configuration files. It should be named using the name of your theme, just like your .info.yml file. Let’s take a look at each line to get a better understanding of all the properties.

Naming

# Give your library a name.
my-library-name:

Each library is given a custom name. This name can be anything, but must be unique to the module or theme that supplies it. This should be easy to keep track of since the libraries that belong to the same module or theme are defined in the same file. The name does not have to be unique to the entire website, because libraries are referenced using both the library name and source. For example, mythemename/my-library-name, but we’ll get to that later when we start attaching and manipulating libraries.

Version

version: "1.0.x"

The version is completely optional. It is only used for identification purposes, along with other properties like license, remote, and a few others that we won’t go into. You may want to add a version for a library you use with multiple projects to keep track of which version is used at any given time. It is also helpful when creating a library that uses CSS or JS from an external source. For example, if you copy code for a slideshow, you may want to add the source version here to keep track of it.

CSS

css:
  # The SMACSS category.
  base:
    # The path to the css file.
    assets/css/base.css: {}
  theme:
    assets/css/print.css: { media: print }

All CSS files are included below the css: line. In this case there are two CSS files, base.css and print.css. Each is listed below a category, base and theme, respectively. These are SMACSS categories, which Drupal 8 uses for all CSS file. See the documentation page on CSS file organizaton.

SMACSS

SMACSS is a method for organizing files and CSS rules. You don’t have to follow it in your theming, but you do need to understand how it works and what categories exist, because it used everywhere in Drupal 8 that you encounter CSS files. If you’ve never used SMACSS before, just know that there are five categories; base, layout, component, state, and theme.

When libraries are processed and stylesheets added to a page, they are added in the order of these categories. So a file in the base category will always come before a file in the theme category. The one caveat to this is all module libraries are grouped together and then all theme libraries, so regardless of category, a theme’s stylesheets will always come after the ones supplied by modules.

Back to our example...

Additional Properties

theme:
  assets/css/print.css: { media: print }

The line below the SMACSS category is where we add the CSS file. The path, relative to the root of the theme, is used to identify the file. Following the file are a pair of curly braces where additional properties can be set. In this case, the media property is set to print. The available values for media are screen, print, or all. If no value is set, all is used.

JavaScript

js:
  assets/js/myglobal.js {}

Like CSS, we add JavaScript files below the js: line, with each file on a separate line. Unlike CSS, there is no SMACSS category to worry about. But, just like CSS, you can set additional properties inside the curly braces following the file name. For example, adding minified: true will tell Drupal this file has already been minified, so don’t try to minify it again when aggregating the files.

One thing to note is Drupal 8 adds all JavaScript files to the footer of a page. If you need to have your JavaScript loaded in the header, add header: true to the library.

my-library-name:
  header: true
  ...
  js:
    assets/js/myglobal.js {}
  ...

If the header property is set to true, any dependencies defined in the library will also get loaded in the header.

Dependencies

dependencies:
  - core/jquery

The dependencies: line is where you add any libraries your library requires. This must be other libraries already defined by your theme, some module, or Drupal core. Notice that the library is referenced using its name, and where it came from. In this case, core. (core refers to a literal core.libraries.yml file. Libraries defined by core modules will use their names; block, node, field, views, system, etc.) This is how we avoid name conflicts.

External Files

lato:
  css:
    base:
      '//fonts.googleapis.com/css?family=Lato': { external: true }

In the second example, we see how to link to external stylesheets. Simply supply the external URL for retrieving the file, and set the external property to true.

Attaching Libraries

There are three basic ways for a theme to attach libraries; in the .info.yml file, directly in a template file, and in a preprocess function. Let's go over each of those methods.

Global

To attach assets globally so they are added to every page of the website, add them in your theme’s .info.yml file.

libraries:
  - core/normalize
  - mythemename/my-library-name

Twig

A great way to attach a library conditionally is to do so directly in a template file. Drupal 8 has a special function called attach_library() just for this purpose.

{# In a Twig template file. #}

{{ attach_library('mythemename/my-library-name') }}

The advantage here is in matching the same conditions of the template file. For example, if you use this method in your node.html.twig, the CSS and JS files will only get added when a node is rendered. If you do it in your node--content-type.html.twig the files will only get added when a node of that particular content type is rendered. You can imagine the flexibility when doing this in specific field or views templates.

PHP

Lastly, libraries can be attached in preprocess.

<?php
function mythemename_preprocess_page(&$variables) {
  $variables['#attached']['library'][] = 'mythemename/my-library-name';
}
?>

Here you can add whatever logic needed to match the conditions you want before adding the library to the 'library' array.

Manipulating Libraries

Since all CSS and JS files in Drupal 8 are now in libraries, themes have complete control over those files, regardless of whether they are part of the theme or not. The two main ways to manipulate libraries are with libraries-extend and libraries-override.

Libraries-extend

Libraries-extend is a property used in your theme’s info file. It attaches your library to any existing library. The real power here is that the inclusion of your library will now match the library that was extended. If there is any special logic behind when and how that library is attached, your library goes along for the ride without you having to do anything to recreate that logic yourself.

# In mythemename.info.yml

libraries-extend:
  # Classy's forums library is only included when the forums.html.twig
  # template is used. This will add my theme's 'forums' library at the same
  # time.
  classy/forums:
    - mythemename/forums

In the above example, a forums library is created as part of our example theme, and attached to Classy’s forums library. Any time Classy’s library gets attached, which is only when a forum is rendered, the example theme’s library also gets attached.

Libraries-override

Libraries-override is an even more powerful property that can be used in your theme’s info file. It gives you complete control over any library, to manipulate in anyway you see fit.

Let’s take a look at some examples.

Remove a File

# In mythemename.info.yml

libraries-override:
  # The library name.
  core/jquery.ui:
    # CSS files are always labeled as such. This format is required.
    css:
      # The SMACSS category is required.
      theme:
        # The path to the file. It is not a path relative to your theme.
        assets/vendor/jquery.ui/themes/base/theme.css: false

You’ll notice the structure is exactly the same as when you define a library in your .libraries.yml file. You specify the library name, SMACSS category, and original path to the CSS file. The only difference being the library name must also include the source. In this case, core is prepended to the library name, because the jquery.ui library is defined by Drupal core.

On the line with the path to the CSS file, note that this path is the same as defined by the library. It is not a path relative to your theme, or the website root. It is exactly the same as defined by the jquery.ui library. The path is used as a key to identify the CSS file, so it has to match. If you don’t know what the path is, just find the .libraries.yml that defined the library, and copy it.

Lastly, in this example we’ve added false after the file. This tells Drupal to remove that CSS file any time the library is used. When we say, “no more PHP”, this is it. Gone are the days of preprocessing or alters, doing string searches, and unsetting array elements.

Replace a File

# In mythemename.info.yml

libraries-override:
  system/maintenance:
    css:
      theme:
        # Replace the System module's maintenance CSS file with a custom one.
        css/system.maintenance.css: css/maintenance.css

Here we have targeted one particular CSS file added by the System module, in a library called maintenance. Following the system.maintenance.css we supply the path to our own CSS file. This path is relative to the theme’s directory. And since we are supplying a file to an already existing library, this file does not have to be part of any other library defined by the theme.

When doing this yourself you’ll also notice that the new file gets placed in the exact same place the original file was linked in the head of a page. Whether the original file was first or seventh, the new file will be the same. This ensures the cascade of rules in all the stylesheets is not disturbed.

Replace and Remove Whole Libraries

# In mythemename.info.yml

libraries-override:
  # Replace Classy's messages library with a custom one.
  classy/messages:
    mythemename/messages

  # Remove Classy's search results library completely.
  classy/search-results: false

In this example, we are doing two things. First, replace Classy’s  messages library with one from the example theme. This will prevent any of the files used in the Classy library from getting used, and replace them with the files in the example theme’s library. Note that your theme’s library does not have to match the original library. You can have more, or fewer, files, and call them whatever you want. This just substitutes your library for the original one.

Second, the false placed after Classy’s search-results library removes it completely. This is similar to how we removed an individual CSS file in the previous example, but in this case we remove the entire library.

Voila!

As you can see, given the all-in approach Drupal 8 has taken with libraries, and the power of libraries-extend and libraries-override, themers now have total control!

Tagged with Comments
Categories: Elsewhere

Jeff Geerling's Blog: Developing with VirtualBox and Vagrant on Windows

Mon, 14/03/2016 - 20:02

I've been supporting Drupal VM (a local Drupal CMS development environment) for Windows, Mac, and Linux for the past couple years, and have been using Vagrant and virtual machines for almost all my development (mostly PHP, but also some Python and Node.js at the moment) for the past four years. One theme that comes up quite frequently when dealing with VMs, open source software stacks (especially Drupal/LAMP), and development, is how much extra effort there is to make things work well on Windows.

Problem: tool-builders use Linux or Mac OS X

The big problem, I see, is that almost all the tool-builders for OSS web software run either Mac OS X or a flavor of Linux, and many don't even have access to a Windows PC (outside of maybe an odd VM for testing sites in Internet Explorer or Edge, if they're a designer/front-end developer). My evidence is anecdotal, but go to any OSS conference/meetup and you'll likely see the same.

Categories: Elsewhere

Acquia Developer Center Blog: Drupal How-To: Get Inline Images on Your Drupal Site.

Mon, 14/03/2016 - 19:35

In this 3-part Drupal How-To series, I'm going to show you various options for configuring images on your site.

In Part 1, we looked at how to tweak the default image options. Here, in Part 2, we'll see ways to allow inline images. In Part 3, we'll see the latest options for responsive images.

Tags: acquia drupal planet
Categories: Elsewhere

Evolving Web: Drupal 8 Theming Foundations: Using Stable vs. Classy as a Base Theme

Mon, 14/03/2016 - 18:09
Drupal 8 Theming Foundations: Using Stable vs. Classy as a Base Theme Suzanne Kenned… Mon, 03/14/2016 - 13:09
Categories: Elsewhere

Evolving Web: Drupal 8 Theming Foundations: Using Stable vs. Classy as a Base Theme

Mon, 14/03/2016 - 18:09

For themers, there are lots of exciting new features in Drupal 8: the Twig tempting system, libraries for loading assets, and the replacement of theme functions with templates. There are also a new set of core themes that come with Drupal 8.

read more
Categories: Elsewhere

Acquia Developer Center Blog: Migrating the Acquia Library from D6 to D8: Learning by Building

Mon, 14/03/2016 - 15:49

This post may be of interest to project managers and sitebuilders looking to migrate from Drupal 6 to Drupal 8 during the early months after the launch of GA D8.

On the Acquia Support Team we often find ourselves using Acquia’s public-facing documentation and article library as an effective tool for explaining product-related tasks, technical how-tos, and a variety of other topics. These resources are useful when communicating via our Support Help Center. Unfortunately, the underlying infrastructure for this site was Drupal 6.37.

Tags: acquia drupal planet
Categories: Elsewhere

J-P Stacey: Drupal 8 embraces composer's bleeding edge

Mon, 14/03/2016 - 12:54

I've long held that I'm happy to treat Drush Make and the rest as transition technologies until Drupal moves fully to Composer. If that day isn't strictly here yet, then it's awfully close.

Read more of "Drupal 8 embraces composer's bleeding edge"

Categories: Elsewhere

Valuebound: Managing user roles & permission in Drupal 8

Mon, 14/03/2016 - 10:58

One of the reason why Drupal is hugely popular for content management application development, because of customizable content authoring workflow. We can simulate good old editorial experience where authors create the article, sub-editor review it and finally editors will confirm & publish if all organization lead criteria are met. In Drupal we create this permission system by creating roles.

Instead of assigning specific permissions to each user, permissions are assigned to roles. And then specific users are assigned role(s) e.g. author, reviewer, editor.

In this post we will explore how to create roles, specify permission for the role and assign specific role to user.

Step 1: First step is to go to Manage >> People >>…

Categories: Elsewhere

Drop Guard: Drop Guard response about insecure update process

Mon, 14/03/2016 - 09:30
Drop Guard response about insecure update process Igor Kandyba Mon, 14.03.2016 - 09:30

6 January 2016 was a memorable day for the Drupal community. Probably for the first time since the Drupalgeddon a vulnerability with potential to affect millions of websites was discovered. The report on the insecure Drupal update process, published by IOActive, got immediate traction and responses from Acquia, Drupal Security Team and major players in the community.

The analysis of the risks, however, showed the impact is not significant enough and as a result, the patches to fix the issues listed in the report are still "work in progress" (first and second).

As the updates automation and security is the Drop Guard's only focus and business model, we feel responsible for providing our answer to each of the issues. 

Issue #1 (part 1): Incorrect update statuses Whenever the Drupal update process fails, Drupal states that everything is up to date instead of giving a warning.

This issue affects the display of the core or contrib update status on the "Available updates" screen, in case the update information is not properly fetched from Drupal.org.

First, Drop Guard users don't need to have the Update module enabled at all (one less module enabled, huh!), as they delegate the heavy lifting updates detection work entirely to Drop Guard. 

Second, under the hood Drop Guard uses a combination of the Update Manager code, rewritten to mitigate most common update process issues, our custom update detection logic and manual checks of the modules in question. It happens quite often, when, for example, the security advisory for a module can not be parsed automatically - in this case, our team investigates the issue and adjusts the update status. 

Lastly, long before the report from IOActive was published, Drop Guard was smart enough to stop the updates detection process if the update information couldn't be fetched. In the unlikely case of Drupal.org infrastructure issues or general network problems the worst thing which could happen - the update won't be available to a user unless its status will be properly fetched and confirmed.

Issue #1 (part 2): CSRF vulnerability The "Check Manually" link can be used to perform a cross-site request forgery (CSRF).

Drop Guard server doesn't use the Update module UI, and don't need it enabled, so there is no risk someone could ever click on the "Check Manually" link at all. We always recommend disabling the Update module on the production sites protected by Drop Guard.

Issue #2: Spying on the network traffic An attacker may point a website owner to a backdoored version of Drupal by eavesdropping on the unencrypted network traffic between a website and updates.drupal.org domain.

Drop Guard users never visit the "Available Updates" page on their websites, which mitigates this vulnerability. Besides, all the networking with updates.drupal.org services is performed over the encrypted connection on our side.

And luckily, Drop Guard users never download updates via the Update's module interface. We highly recommend not to use this functionality for any Drupal maintainer and use the proper updates and deployment workflows instead.

Issue #3: Unencrypted updates transfer Drupal security updates are transferred unencrypted without checking the authenticity, which could lead to code execution and database access.

As mentioned in the section above, Drop Guard always uses the encrypted connection when fetching updates information from Drupal.org.

The actual update archives from Drupal.org are fetched to our servers via the encrypted connection as well. It's also worth saying that Drupal.org team is working tirelessly to switch infrastructure and update processes to use secure channels, so when trying to access the http://updates.drupal.org/release-history/drupal/7.x for example, you will be redirected to the encrypted version automatically.

So as we can see, the easiest way to ensure that you're not in the risk group (apart from using Drop Guard obviously), is to check if the Update Manager is enabled and if it's used to fetch actual updates to your server.

The latter practice can not be recommended for any beginner or advanced user. You should be using proper development workflows and practices instead.

Do you still use the Update Manager module to update your Drupal installation? Do you think it's a good practice? What's your experience overall? Please do share your thoughts in comments!

Security infrastructure Drupal Planet Drop Guard

View the discussion thread.

Categories: Elsewhere

DataSmith: Git Bisect: The go-to tool for answering the "when did this stop working" question

Mon, 14/03/2016 - 02:24
Git Bisect: The go-to tool for answering the "when did this stop working" question

Continuous integration and automated testing can significantly reduce the odds of regressions, but eventually, every project will fnd themselves facing a feature that used to work and no longer does.  When that time comes for you, I recommend git bisect.

Barrett Sun, 03/13/2016 - 21:24
Categories: Elsewhere

Promet Source: Think Fast! Playing Drupal Trivia at MidCamp

Sun, 13/03/2016 - 23:08
Time to break out your best Drupal knowledge, Chicago! Demonstrate your Drupal genius at #MidCamp this year.

 

Do you have what it takes to be quizmaster at Promet Source's booth during MidCamp? Promet is inviting the community to participate in a friendly round of Drupal trivia during MidCamp activities Friday, March 18 and Saturday, March 19, 2016.

Categories: Elsewhere

Drupal core announcements: Drupal core security release window beginning Wednesday, March 16, 2016

Sun, 13/03/2016 - 19:02
Start:  2016-03-16 00:00 - 23:30 UTC Organizers:  xjm catch David_Rothstein Event type:  Online meeting (eg. IRC meeting)

The monthly security release window for Drupal 8 and 7 core will take place on Wednesday, March 16.

This does not mean that a Drupal core security release will necessarily take place on that date for any of the Drupal 8 or 7 branches, only that you should watch for one (and be ready to update your Drupal sites in the event that the Drupal security team decides to make a release).

There will be no bug fix or feature release on this date. The next window for a Drupal core patch (bug fix) release for all branches is Wednesday, April 06. The next scheduled minor (feature) release for Drupal 8 will be on Wednesday, April 20.

Drupal 6 is end-of-life and will not receive further security releases.

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Categories: Elsewhere

Drupal Association News: Measuring Drupal's health

Fri, 11/03/2016 - 22:45

The Drupal community is diverse. We're from different places. We speak different languages, code in different languages, and use Drupal in different ways. But the one thing we all have in common is that we care about the fate of Drupal. We invest our time, intellect, and emotions into this project. And we want that investment to make the project successful.

We have a lot to be proud of. In the last few years, Drupal use and community contribution has grown tremendously. Some metrics—like comments and commits created each month—are available at drupal.org/metrics. We share project usage and track BuiltWith statistics. We've also started reflecting company contributions in the marketplace and on organizations list.

The Association's mission is to unite a global open source community to build and promote Drupal. One of its 3-to-5 year goals is to ensure the sustainability of our project and community. To meet that goal, we need to get much better as a community at answering the question: Is Drupal healthy? But that's not an easy question to answer.

In the last board meeting, board members and staff talked about what kinds of metrics show health. In this post, I share some of that thinking, and ask for your ideas. But before we get into recommendations, let’s start at the beginning.

What's project health?

Association staff and board members use “project health” as shorthand for project success. "Health" is robust. Think about your own health. You might think first about physical aspects (Do I have a fever?). But you also might think about emotional aspects, like depression or stress. You may even think about social aspects (Do I have the right people around me to support me and keep me focused on the right habits?). Health isn't binary. Health is multi-dimensional.

So, too, is the health of an open source project. It's easy to take the temperature of a project with metrics like usage or number of committers. But to understand the complexity of our project's health, we need broader measurements. In our work on staff, we've defined four dimensions of product health1 we think we need to explore:

  • Product: whether the business of the Drupal product (the software) is sound. Examples of areas to explore: marketshare; Drupal businesses' revenue.
  • People: whether we have the right kinds of people contributing the right kinds of things. Examples of areas to explore: number of contributors; kinds of contributions; contributors' skills.
  • Process: how the way we do things contributes to the project. Examples of areas to explore: ability to meet published release dates; succession planning.
  • Systems: whether we use the right tools. Examples of areas to explore: testing times for DrupalCI; amount of documentation edits; responses to posts in forums; issue resolutions; commits and integrated repositories.
Acknowledging our limitations

There's the ideal, and then there's reality. We know we won't be able to track everything we want to. So, we'll have to make choices. We'll have to choose metrics that give us directional, even if not precise, accuracy. So, what are some of our limitations?

The future of the project

Knowing what categories of metrics we need to track is necessary, but not enough. Setting metrics also requires knowing where we want the project to go. Taking your temperature is only helpful if you know what you want it to be (and what it means if it's not).

This is a challenge Association staff discussed with the board. The Association doesn't set the software's future. It does, though, need to know where the project is going. To support the project's journey, it needs to know its direction. For example, maybe headless Drupal is the future. If so, we might measure “People” success by how many JavaScript developers contribute. But it’s not 100% clear what the future holds for Drupal. We have work to do before we can identify the best metrics.

Resources

Tracking project health is an Association priority, but it’s not its only mandate. It has to consider the time and expense invested in DrupalCons and Drupal.org too, for example. Unfortunately, budget limitations mean not hiring analysts or consultants to help. For the most part, they mean working with the (wonderful) people already on staff.

So, for example, measuring contribution only by code or comment attribution isn't enough. People contribute in so many ways. (There's even an issue open on this topic already.) Will measuring contribution expand to include other things? Yes. But will it also likely still not give some contributions the attention they deserve? Unfortunately, yes. Hard choices will mean we'll all have to accept some less than ideal outcomes.

Balancing competing frames and other fun factors

Once we know what outcome we want and have found things we can actually measure, we'll still need to do more. Any metric we choose has to also align with the project's mission and our community’s values. We also can't be too dependent on internal metrics. We'll have to measure our success with external indicators too. (See? There's a lot to think about here!)

Examples, please

There’s good news and bad news here. The good news is that we are definitely not alone. Many software projects—including open source projects—have worked on these same issues. There are resources all around us. We've created lists of some of them already.

Bitergia dashboards Open source projects on GitHub Project-run dashboards So what should we track?

There's a lot to consider when we think about the health of the Drupal project. We've just begun this conversation and want to make sure you're part of it from the beginning. So, now we turn things over to you.

Which metrics are indicative of Drupal project health? Share your ideas in the comments section. We'll include your feedback in a document we'll share with you.

1 We borrowed these concepts from Product Lifecycle Management.

Flickr photo: Thomas Haynie

Categories: Elsewhere

ImageX Media: QA: What Does It Mean to ImageX and Our Clients?

Fri, 11/03/2016 - 20:53

Quality Assurance (QA) bridges technology and user experience design, giving a big picture and wind angle understanding of systems and projects. It adds value to the development process, not just by ensuring that every project meets our standards of excellence, but also by defining and maintaining the focus of the team through the entire lifecycle.

Categories: Elsewhere

Pages