Inhalt abgleichen
Drupal.org - aggregated feeds in category Planet Drupal
Aktualisiert: vor 10 Minuten 22 Sekunden

marvil07.net: A release plan for contributed drupal extensions

25. Oktober 2017 - 3:51

tl;dr: Review the plan at the end directly.

Software has a changing nature; Drupal and its extensions are not the exception.
To be useful for a most of the users, those need to be on full releases, not only on the version control system; indeed the problem is not new and there is even a well-known phrase for one of its solutions: release early, release often
Therefore it is important to have a release plan.
Following after some context and reasoning, I propose a couple of practical guidelines on release schedule for contributed drupal extensions that I intend to use: release weekly until stable, then once a month following core shedule.

On the changing nature of software

Software inherently tends to change, there are exceptions like embedded systems or really purpose-specific software.
Even really solid software like GNU core utils project, started on 1992, which provides tools that I consider among the most mature in the software space used daily, has 253 commits and three point releases in the last 12 months[1].

How much a software change depends on many factors.
I would hypothesize that the most relevant factors are the age of the project, the environment around it, and the amount of people behind it.
In this way, new projects change more than well established projects, and projects around dynamic environments which is also influenced by the amount of people around it, will also change more than the ones in environments with less participants or less technology changes.

How changing are contributed drupal extensions?

Drupal contributed extensions are naturally mainly influenced by drupal core, so let us examine a bit how changing is Drupal core.
It is definitely on a dynamic environment, and I will argue that each major release can be considered a new project, making it really changing.

On the dynamic side, even if web standards changes slowly, and for good reasons, technologies around web tools are still constantly changing.
The stack has changed a lot over the years, and even if some tools like apache and mysql/mariadb are still around, other parts of the stack has been changing a lot, especially around client side javascript.

Drupal core project code history is now 17 years old, which seems like enough time to get into a stable state, especially if you are not yet part of the drupal community.
But the drupal project has a history on rewriting the way its internal works, which has been argued as one of the reasons why drupal can keep up with the changing environment around web technologies.
It may be also a consequence of its amazingly collaborative community.
And because of this rewriting between major versions, at least internally, each major release can be considered a new project, especially with 8.x.x.
A hint about it may be reflected in the fact that major contributors across different drupal core versions are mainly different; only a few one are as active across releases.

In consequence, drupal core is still a highly changing project, and in the same way its extensions inherit part of that changing nature; but a contributed drupal extension is not really only influenced by core.
Given the amazingly high number of written extensions, it is only natural to start depending on other software pieces and make its maintenance more effective.
For instance, currently there are 13432 and 4069, D7 and D8 compatible modules respectively.

In this way, one of the factors that will clearly influence a contributed extension is their dependencies, both inside and outside the drupal, and how changing they are.

Another factor is the amount of people behind it, not only developers, but also users reporting bugs.
For drupal contributed extensions this vary a lot, but it is usually not that big.

For all this, contributed drupal extensions are usually in a changing environment.

Commits are not releases: release early, release often

As a contributed module developer myself, I will start by mea culpa.
Sometimes I wrongly assume that when a change is inside git the work is done, but that may be only true for people willing to take the extra effort to get the changes from git, or assume the consecuences of using a development release.
Commits are a developer tool inside the used version control system, but not necessarily something that is visible/usable for all.

As in many occasions, the problem is not new, and I find a pretty good answer for it on "The Cathedral and the Bazaar" chapter 2: Release early, release often.
It mainly propose that to be able to tackle enough bugs to make the software usable, the amount of releases needs to be as fast as the pace of the development, even at the cost of some stability.
I definitely recommend reading it fully for more context, and a lot more inspiring insights for any open source developer.

How often is often? A release strategy plan

Granted, the answer is not a recipe, and it makes sense it is that way because it really depends on the project.
On the following lines I will propose an specific release strategy for drupal contributed extensions.

Drupal core already has a release plan, it is really detailed, so please review it if you have not done it yet.
Minor releases are approximately available every six months, but security and bugfix releases for a given minor version branch are available monthly, on third and first Wednesday respectively.

Security releases for drupal contributed extensions are published in coordination with the security team, so there is no need to plan them here, they also happen on Wednesdays.

Making it simple to remember can help maintainers stick to it, so I will also be using Wednesdays as well as the weekday for releases.

The plan

I propose the following for each supported major branch in contributed extensions:

  • release alpha/beta/rc weekly on Wednesdays, until a stable is ready
  • release bugfix releases once stable has been reached in the same schedule than core, i.e. the first Wednesday of the month;

Looking back, it seems obvious and really simple, but if it is not documented somewhere, I will probably forget about it.
Hopefully someone else finds this useful, or even better wants to do the same.
Having a more predictable schedule always help to make better planning decisions.

I will start this week using this two guidelines and release a new version in the modules I maintain and there are pending changes to be released.

Auto-notify maintainers

Notifications may help us maintainers to stick to this, but I guess the plan itself was relevant enough keep the focus of this post.
I may be exploring some solutions around it in the future.

[1] To reproduce statistics you can retrieve the main repository from https://git.savannah.gnu.org/cgit/coreutils.git and then run a couple of commands:
git log --oneline --all --since="1 year ago" | wc -l git log --oneline --all --since="1 year ago" --decorate | grep tag

Etiquetas:

Agiledrop.com Blog: AGILEDROP: First days on board with A-team

25. Oktober 2017 - 3:05
When new developers arrive in our team, our mission is to help them as much as we can in every aspect of adaption to the new job environment, so they can show their potential and shine in their best light. First days at a new job are really important. Based on first impressions developers form the picture about their new coworkers and about the company itself, and that can have an impact on long-term. We pay great attention to the first days with us, so we prepared a brief insight in first work days at our company. First day We show the new developer around, show the desk and her… READ MORE

Agiledrop.com Blog: AGILEDROP: Why should agencies partner with companies rather than hire freelancers?

25. Oktober 2017 - 1:38
Digital agencies sometimes get in a position when they have more work their internal team can handle. For many outsourcing is not an option, as they still wish to keep the project in the house, but are open to working with external developers. Agencies can hire freelancers or work with teams like AGILEDROP. In this post, I will highlight some of the advantages of working with a team that agencies often overlooked when making a decision. No more job posts and screening interviews Hiring a freelancer is practically the same as hiring a full-time employee. First you have to write a job ad and… READ MORE

Manifesto: City of Drupal: thoughts on DrupalCon Vienna 2017

24. Oktober 2017 - 18:51
It seems like a long time ago now… Well. It was…. At the time of writing, it’s three weeks since I was at DrupalCon. I could argue I’ve been taking time for reflection, but actually we’ve been super busy and so I’m just getting round to penning my thoughts and memories of my week in. Continue reading...

Drupal Modules: The One Percent: Drupal Modules: The One Percent —Create user permission (video tutorial)

24. Oktober 2017 - 17:29
Drupal Modules: The One Percent —Create user permission (video tutorial) NonProfit Tue, 10/24/2017 - 10:29 Episode 41

Here is where we seek to bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll consider Create user permission, a module which allows users to create other users without granting all the permissions administer users provides.

Blair Wadman: Override Drupal 7’s page template for a content type

24. Oktober 2017 - 17:06

Creating a page template for a content type gives you a lot of control over the structure of the page. While Drupal will automatically pick up a node template for a content type, if you use the right naming convention, it will not for a page template. Fortunately it just takes a few lines of code and you can create a page template for any content type you choose.

Deeson: Deeson at DrupalCon Vienna 2017: Excellence in the tech team

24. Oktober 2017 - 15:43

In my previous post I shared key takeaways from a Birds of a Feather (BoF) session I ran at DrupalCon Vienna last month on what it means to be an Agile agency

Another BoF session I ran invited conference attendees to share their experiences of managing team members and ensuring technical excellence. We covered each topic in a lot of depth, and at times it felt a bit like a counselling session for new and aspiring tech leads!

Here’s a snapshot of what we discussed:

Overcoming resistance to change.

The group debated how best to roll out changes within the tech team, such as changing version control software to git. Tech leads don’t always feel empowered to force through new initiatives, and can get frustrated by developers who either don’t want to change or are unable to see the benefits.

We spoke about the need to introduce change gradually and gain buy in through mechanisms such as team meetings, highlighting the importance of allowing changes to be discussed and concerns to be heard.

It can be helpful to identify evangelists in the team who will promote the change, and can act as support contacts during the period of transition so that no one suffers in silence.

Leading change in remote teams.

Change is hard enough when you’re all in the office together – how do you ensure a smooth transition in co-located and distributed teams?

At Deeson, we’ve introduced a quarterly get together in person. We set up the changes the tech chapter plans to make over the next quarter, and assign owners to develop the ideas and facilitate the transition process.

We also run group workshops on the changes made during the last quarter, allowing people to gain hands on experience with a new tool or technique under the supervision of those that specified it and their evangelists. This allows us to identify any problems and concerns before the change is mandated.

Dealing with complaints.

It’s natural and healthy to express concerns or frustrations. But what do you do when a team member seems to complain more than most? 

As a manager you feel responsible for solving every issue that arises, and of course there are times when the onus will rightly fall on you.

However, in the case of a chronic complainer it can be more effective for you as tech lead to listen to the grievance and empower the person to consider their options and suggest solutions, rather than exhaust yourself trying to solve the issue on their behalf.

Transitioning to tech lead.

Often a developer progresses until they one day find themselves leading a tech team, without ever having received any formal leadership or management training. We spoke about the changes you need to make, and how to understand what’s expected of you in your new role.

We cited the book The Manager’s Path by tech lead turned CTO Camille Fournier as an excellent reference. The Lead Developer conference which takes place annually in London is another good resource. Talks are made available online and provide a lot of guidance to those new to the tech leadership position.

Here’s one of our favourites:

Want to work with the largest Acquia Certified team in Europe and one of the top 30 companies contributing to Drupal globally? We’re hiring.

CiviCRM Blog: CiviCRM Comes to Serbia

24. Oktober 2017 - 9:29

With the funding environment for nonprofits in Serbia becoming increasingly more fragmented and the choice of technology tools to aid fundraising and advocacy becoming more diverse, Catalyst Balkans saw an opportunity to fill an open niche for a localized CRM targeted to the nonprofit sector in the Western Balkans.  With Catalyst Balkans already having used CiviCRM for several years for its own communication and contact management needs, the localization of CiviCRM was a natural choice.

With virtually zero strings translated into Serbian on Transifex and a very limited budget, Catalyst used a combination of existing staff resources and volunteers to plug away at the translation effort over a period of months.  The final 1500 strings were done with the help of a translation professional who also went through and polished the entire translation file. 

Many coffees were spent in conversation about the best (and shortest) translation of a string.  Concepts like a ‘pledge’ or acronyms like LYBNTY proved to be a huge challenge to get right.  And it also gave our staff coffees a whole new linguistic flavor (and made some of us wish we had a little extra nip of something to slip into the coffee).

However, after nearly 7 months of effort, we completed the translation and were thrilled with the results as we installed it onto a Drupal implementation.  Then we broke out the drinks and made coffee hour into happy hour.

Subsequently, we have continued with the translation of several extensions, including the Mosaico mail extension.  With the translation complete, we have worked with 9 nonprofits to set up instances in Serbian to beta test the translation and provide us feedback on improvements that could be made.

With this experience in hand, we are launching an effort to provide full translations of CiviCRM and key extensions into Albanian, Bosnian, Croatian, and Macedonian over the next year.

This will allow CiviCRM to access a market of more than 130,000 nonprofit organizations across the 7 countries where there will now be a fully localized CRM solution for them to use and a service provider who will provide hosting, support and training in using CiviCRM for improved fundraising, more effective advocacy and increased constituent engagement.

Nathan Koeshall, 

Director and Co-Founder of Catalyst Balkans

CiviCRMDrupalInternationalization and Localizationv4.7

ADCI Solutions: How to build a single-page application (SPA) with Vue.js

24. Oktober 2017 - 5:34

Everybody seems to build SPAs now. Single-page applications are a big deal: they provide good UX, speed; provide the full control over the markup in Drupal.

We played with Vue.js a bit, and created a simple SPA application. You can use Drupal on the back-end: you’ll find the necessary instructions inside of the article.

 

Read the full article.

 

 

Stanford Web Services Blog: Altering Custom Elements in Forms

23. Oktober 2017 - 22:46

Drupal provides a powerful framework for creating custom elements for use in forms. One example of a custom element is the Link field. Suppose you want to change the default label on a Link field to read "Link text." How do you alter it?

Matt Glaman: ContribKanban.com: What's next

23. Oktober 2017 - 22:24
ContribKanban.com: What's next mglaman Mon, 10/23/2017 - 15:24

Back in 2015, I created ContribKanban.com as a tool to experiment with AngularJS and also have a better tool to identify issues to sprint on at my previous employer before Commerce Guys. At the Global Sprint Weekend in Chicago, I received a lot of feedback from YesCT and also ended up open sourcing the project. That first weekend made me see it was more useful than just being a side project.

Zivtech: Decoupling Drupal: Our Experience with NowAnThen.com

23. Oktober 2017 - 11:14
What is Decoupling?

Decoupling has been gaining momentum in the past couple years. An increasing number of websites and applications combine their content management system’s backend and editorial capabilities with a separate framework that renders the front end. 

The idea is to make data available in a different format (usually JSON) so the framework can parse it, and so the developer can take full control of the markup, UI, routing, etc. While it’s not ideal for certain types of sites (if you have a lot of pages for instance), it becomes very handy when dealing with single page applications or projects that require a lot of user interaction.

I recently attended Decoupled Dev Days in New York City. This two day event was a way to gather a small portion of the Drupal community (and others) for an in-depth look at the work many people are putting toward making Drupal an attractive backend for a decoupled app. Guest speakers were also main contributors for Angular.js and Ember.js, which was beneficial; the goal was not to make another Drupal centric conference, but rather to attract a broader audience within the tech community.

It was a great opportunity to see the community at work and to get insights about implementation, performance, tools, and more while working on a decoupled app myself.

Read more

Agiledrop.com Blog: AGILEDROP: We can join in the middle of the project

23. Oktober 2017 - 9:22
When talking about projects, regardless of their size or complexity, one will go through a couple of phases of project management. Let’s say there are five phases of project management:  project conception and initiation;  project definition and planning;  project launch or execution;  project performance and control;  project close.  Although each of those phases has its distinct qualities, they do overlap. And rightly so.  Planning for unplanned events Planning does start with estimating the budget and completion date, but the planning and defining the project sets the… READ MORE

heykarthikwithu: Composer in Drupal 8 - Manage dependencies

23. Oktober 2017 - 8:02
Composer in Drupal 8 - Manage dependencies

Install Modules/Themes via Composer in Drupal 8

 

heykarthikwithu Monday, 23 October 2017 - 11:32:54 IST

Promet Source: Ask Promet Accessibility: The Intersection of Accessibility & Usability

20. Oktober 2017 - 23:19
Question: Do I need actual disabled individuals to audit and test my site?

Lullabot: A Software Developer’s Guide to Project Communication: Part 1

20. Oktober 2017 - 19:32

The key to a successful project is good communication.  Honesty and directness about timelines and scopes of work go a long way to relieve pressure from the development team and avoid frustration from stakeholders, but what about the day-to-day information exchanged between developers, designers, and project managers? This is the grease that keeps the project running smoothly and should not be overlooked.

As teams vary in size, so do the roles and responsibilities of individual team members.  Smaller teams have fewer communication channels, so you may need to switch between your developer hat and project manager hat frequently.  On larger teams your hat rack may be quite sparse, but the number of communication channels, and thus the possibility of miscommunication, is far greater.

Regardless of the size of your team, information about the project must be communicated and documented effectively.  From very large teams to projects where it's just me, I've learned how damaging even minor miscommunication can be.  Conversely, you look like a hero when you get it right.  Stakeholders, project managers, and developers work in very different realms. In this article I'll discuss a few overarching principles that I've learned to help navigate the monsoon of information blustering through a project.  They will help you regain control of your time and create a more productive and successful project.

What is Communication?

Existentialism aside, what do we really mean when we talk about communication?  Communication is an exchange of information between parties.  The parties may be people, but they may also be project management tools.  From video conferences to GitHub notifications, these are all part of the project communication landscape and require different levels of attention.

Forms of Communication

Here are some of the most common methods of communication I've dealt with on projects:

  • In-Person Meetings
  • Voice conference
  • Video conference
  • Chat
  • Text message
  • Direct Email
  • Email Notifications
  • Project Management Tools
  • RSS Feeds
  • Twitter
  • Mobile Notifications

All these types of communication serve a unique role. We wouldn't use them if they weren't helpful, but the question we really should be asking is, "are they necessary?"  Gone unchecked, many of these tools can overrun each other and tangle the workflow.

For example, Slack is a great tool for team members to quickly exchange information between each other, but numerous tools can also post updates into Slack.  A few may be helpful, but too many can dilute the conversation and the effectiveness of the tool.  So how do you find the balance between effective and over-communication?  We can start by categorizing these forms of communication into two groups: active and passive.

Active vs Passive Communication

I find it helpful to group all communication into two categories: active and passive.

Active communication is a two way street.  The sender is expecting a direct response.  Google hangouts, Slack discussions, and phone calls are all forms of active communication.  There is an immediate reciprocation between the parties involved.  You wouldn't invite someone to a conversation just to read them the backlog of tickets, would you?

Passive communication, on the other hand, does not require a direct reply.  This is not as easily definable as active communication.  Let's take a look at email as an example.

If Stakeholder Sarah emails you a question about the next deadline, that is active communication.  She is expecting a response from you in a timely manner.  When a Github notification shows up in your inbox informing you that your pull request has been merged, no follow up is required.  This is passive.  Now, if you receive an email from Jira Notifications because the client asked a question on one of your tickets, which category does that fall under?  It's a notification email, so you shouldn't respond to it directly, but the client is expecting an answer.  Ultimately it depends on the ground rules for communication you set for your project.

Setting Expectations

I tend to follow this order of urgency for response, from most urgent to least.  It's important to agree on a set of communication guidelines at the beginning of a project so everyone on the team follows the same expectations.

  1. Live Communication If you ask me a question face-to-face, of course I will respond to you right away.
  2. Chat Chances are that unless I've set my away message, I'm receiving chat messages in real time.  However, I might be neck-deep in some code or preoccupied in another conversation, so I will respond as soon as I can, but maybe not be right away. 
  3. Mentions in Comments Comments in Jira tickets or GitHub pull requests will likely go unread even if they show up in my inbox unless I am specifically mentioned in them.  I get a lot.  The convention to use the @ symbol to mention another person links their account in the ticket and generates more specific notifications for that person.  It the difference between saying something needs to be done and asking someone to do something about it.
  4. Email I use a couple of email addresses to keep my interests separate so I use an email client to aggregate them into one management space.  However, I find constant email notifications and alerts distracting, so I don't keep my email client open when I don't need to (more on this later).  If you email me, I will probably get back to you within the day, but don't rely on me standing by my inbox waiting to reply to you.  This rule is so important to us that we actually wrote it into the Lullabot Employee Handbook along with a few other tips.
  5. Unmentioned Comments I will likely still get email notifications about activity on repositories, projects or tickets I'm watching or otherwise related to, but if you don't mention me in the comment, it will disappear into tornado of notifications and chances are I won't see it unless I'm reading the backscroll on the ticket.

These are just my rules, but they have worked well for me so far.

Understanding the communication landscape of your project is a necessary foundation.  Setting the proper expectations will prevent miscommunication and keep the project running smoothly.  So far we've identified some of the most common pitfalls and laid the groundwork for a fluid project.  In the next two articles of the series I'll provide advice for managers and stakeholders on how to communicate effectively with the development team and also offer some recommendations and tricks for handling the number one offender when it comes to communication overload: email.

InternetDevels: Spice up your Drupal 8 menus with the Superfish module

20. Oktober 2017 - 14:14

Let’s talk about secret ingredients in menus. Like the right spices, they create special flavours that your guests really enjoy. When it comes to your Drupal website menus, the recipe is simple: just add some jQuery! Using the Superfish Drupal module, which integrates the jQuery Superfish menu plugin, you can create interactive multi-level menus with exceptional usability features. Let’s see how it works on Drupal 8’s example.

Read more

Deeson: Deeson at DrupalCon Vienna 2017: Becoming an Agile agency

20. Oktober 2017 - 12:51

Last month a few of us in the team attended DrupalCon Vienna with fellow Drupal enthusiasts and developers from across Europe and further afield.

Over the three days, my teammates and I hosted several Birds of a Feather (BoF) sessions between us. The format is more participatory than a traditional talk, so it’s a great opportunity to engage in discussion and hear other perspectives from within the community. 

Deeson has been delivering digital projects since 2001, refining our agile delivery process over the years from the DSDM Agile Project Framework in combination with other agile practices particularly suitable for an agency environment.

My first BoF session invited other conference attendees to share their experiences (the highs and lows), tips and best practices for making Agile work in an agency. The following is a roundup of what we discussed over the hour.

Starting slow.

We identified that the typical journey sees agencies start off being ‘agile’ with a small a. They have begun to implement some of the process tools around agile, such as SCRUM, standups, sprints and so on, but aren’t yet living by the core elements of the Agile Manifesto.

Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.

Agile Manifesto

Including the client.

We talked about whether the client should be an integral part of the delivery team or should be kept at arm’s length. Those who believed they had an Agile workflow suggested that the client should be part of the team and involved throughout. The benefit being that – as part of the team delivering the product – they share the risk with delivery.

Those who felt they still had some way to go in becoming Agile were more wary of this approach, believing the client either couldn’t take on these roles or wouldn’t want to. These agencies were more likely to retain full control of the project and client, and accept all the risk as a result.

Handling changing requirements.

There was a discussion about the time taken up with dealing with change, and how clients don’t always appreciate the efforts involved in managing their changing requirements. I described how we deal with this at Deeson with our Dual board in Jira.

This process separates new ideas neatly from refined and signed off units of work ready for development. The client can see their backlog of new ideas and what state each is in, and knows that effort will be involved in taking those ideas from concept to ready for development.

We also considered the need for developers to be able to highlight to a client when an idea is completely new, and to prevent them from trying to squeeze additional functionality into a sprint which already had been signed off.

It’s good to have a SCRUM master or some level of leadership position in the team so developers don’t have to make these decisions themselves and can defer to someone else if they are unsure.

Questioning sprints.

Someone raised the idea that sprints were a waste of time in a truly agile project. They suggested that nirvana could be achieved with Kanban alone; there is only work in progress and with an engaged client and team you would be constantly refining the backlog so new work could constantly be pulled in and worked on. This works well in a model where the client has you on retainer as their technical team for a long period of time (rather than to deliver a specific thing, like a website). 

So there’s always a finite amount of WIP (work in progress). If stories are always refined to the point that they are about half a day's effort for one person, and are complete (finishing them can be tested and, in theory, released) then you can calculate the velocity and the time remaining on sections of work fairly accurately.

We invest heavily in agile training for our staff and clients, and we’re currently hiring for multiple roles including a Delivery Manager.

Valuebound: Selenium: A beginner guide to automation testing tool

20. Oktober 2017 - 10:02

Before delving into the how of automation testing using Selenium, let me talk about the why.

Over the past couple of years, the demand for automation has increased at an unprecedented speed and scale as it indispensably minimizes the testing time, eliminate repetitive human tasks and make life easier. The advent of an open source automation testing tools, such as Selenium, has significantly reduced the demand and scope of manual testing.

Needless to say, every testing has its own quirks and best practices! However, there are certain standard best practices that generally apply to most automation, too. Let’s review the best practices of automation testing. You…