Community

It’s That Time Again: Contribution Time

Have you ever contributed to an open source project? 

You’ve probably seen contribution days listed during conferences, talked to developers who have made their own contributions, and had your own ideas about what would work best for the future of a project. But have you actually contributed?

Contributing to an open source project is one of the best ways to learn more about it, become a member of the community, and influence its future. Without contributors, the project probably wouldn’t even exist.

Ahead of Miguel Balparda’s session at Mage X Austin, we’ve prepared a short article on why you should be contributing to the Magento community – and how you can. 

Why Contribute to Open Source?

Contributing to open source is one of the best things you can do to give back to the community. For many open source users, they’ve been given access to a free product with a large team of developers working behind the scenes to make sure it’s production ready.

Eventually, giving back to that community is going to become a priority. If not to support the community and its continued existence, then to influence its development and future direction, or to just become an active part of that community. 

That’s not all. Contributing is a great way to learn about the software you are using. For Magento 2, this means becoming an expert in how to optimize and take full advantage of its functionality as an ecommerce platform. By being a contributor, you will probably gain a better understanding of the ecommerce platform than devs that just create sites. 

Important Contribution Considerations

If you’re thinking of contributing to Magento - or any open source project - there are a number of things you should consider.

Firstly, you need to bear in mind that open source projects are community driven. People contribute to them: not robots. For this reason, it’s important to maintain a level of respect and professional courtesy at all times. This means more than just being polite in your interactions; it also means checking your code. 

You should not be sending pull requests for code you haven’t checked yourself. Test your code before submitting it. And don’t just gung-ho your own, if there are templates or guidelines: follow them. 

Templates are vital because without them open source projects can quickly descend into chaos. Magento 2 is one of the largest ecommerce projects out there. There are over 1000 contributors, thousands of open issues, and over 240 pull requests every month. Without some kind of coordination, the Magento 2 community would quickly struggle to continuously deliver high-quality and much-needed updates. 

How to Contribute

So how do you actually start contributing? 

The good news is that you don’t have to be a coding mastermind. Typos and translations are also vital parts of the contribution process, and can go a long way in developing the project. 

The first step though, is to fork a GitHub repository and start working on something. This will give you insight into the contribution process and how it works. You don’t have to commit anything to begin with – just play around and get comfortable with the process.

For Magento 2, you’ll find CONTRIBUTION.md in the root directory. Here, most current contribution needs are covered. By joining the community engineering Slack channel, you’ll also be able to have a direct and clear line of communication to other developers and community maintainers. 

Ready, Get Set, Go

So, are you ready to get started?

Head to the Magento 2 repository today and learn some of the fundamentals ahead of Mage X. Then, make sure to bring any questions you have to the incredible community members. Each and every one of them will help you to become an even better contributor and ultimately build on and make Magento 2 community edition even better than it already is. 

Interested in learning more about the contribution process for Magento 2? Make sure to catch Magento Master Miguel Balparda at Mage X Austin, and listen to him discuss Maintaining an OSS project. 

Merchants Are from Mars, Developers Are from Uranus - By Mark William Lewis

Mark William Lewis is the Founder/CTO of Netalico Commerce, an empathy-driven, merchant-focused eCommerce consulting agency, specializing in Magento and Shopify development, where his primary job responsibilities include: Choosing all the emojis in Asana for projects, posting cat pictures on the Netalico #pets slack channel, and tweeting way too much. 

The topic of his presentation is: “Thinking about communication as a developer, manager, or merchant in the ecommerce development process.”

Whether you’re a merchant, project manager, developer, or somewhere in-between, if you work in eCommerce, you probably have to interact with a member of one of these groups daily. And you might have thought at some point “It feels like we’re speaking completely different languages” because it seems like you told someone exactly what you meant, but they didn’t understand you. 

Misunderstandings are particularly rampant in this day and age where so much communication takes place remotely over the phone or text where you lack verbal cues or even vocal inflection. With poor communication, you might get the project done eventually but the road you have to travel to get there is disorganized and creates a distrust that makes it so much harder working together. Communication has a compounding effect over the life of a project or working relationship and is often the biggest factor in the success or failure of the project. If a project fails because of some sort of technical limitation or even just poor sales at the end of the day there are often no hard feelings. But if a project fails because of poor communication, it usually leaves a very bad taste in everybody’s mouth and will likely prevent you from working together on any project in the future or getting a referral.    

In my talk, I’m going to give you a secret Babel fish for translating developer-speak to merchant-speak and vice versa. (With the global development community, actual language might be a barrier, but that’s a different subject.)

Communication Paths

There are many different communication paths, each with their own nuances. If you approach communication from a place of empathy, you can make the road much smoother and enjoyable for everyone. (It might even result in some cost savings!).  

These paths include (but are not limited to!):

  • Developer to Merchant
  • Merchant to Developer
  • Developer to Manager/Intermediary to Merchant
  • Merchant to Manager/Intermediary to Developer

Developer to Merchant

I’ve been a developer for over 50% of my life now, so this is the communication path I’ve had the most experience with. It’s also the one I’ve had to improve the most because when I started as a developer, I was a terrible communicator. And in the past year, I also had the unique experience of having a stroke and having to rethink and rebuild my ability to communicate from scratch over the course of a few months. Through that experience, I was able to watch my communication methods evolve in real-time as I recovered. (Fortunately, I have a great team that took over a lot of the communication during my recovery as well as very understanding clients that weren’t offended by my terse emails and conference calls for a few months.

There are fantastic services like Commerce Hero that connect merchants directly with developers that can cut out the “middle man” of an agency. However without some coaching and instruction, some merchants and developers are going to find themselves incompatible with each other; and this has nothing to do with their technical skills or abilities, but rather their communication skills. To have a pleasant experience they’ll either need to find a developer or merchant that fits their communication style, find a project manager to act as a filter/translator, or learn on their own how to modify their communication to be more compatible with each other.

Let’s get into some real-world examples. Suppose a client writes this email to the developer:

From: Merchant

To: Developer

Subject: Urgent Checkout Isn’t Working!!!

Body: Customer service just got a call and a customer reported the checkout isn’t working. Help!!

10 years ago this might have been my response:

From: Developer

To: Merchant

Subject: Re: Urgent Checkout Isn’t Working!!!

I checked the site and everything seems fine.

Factually, this response might be correct because the checkout might actually be working fine and the customer reporting the issue just has some weird Chrome extension breaking their browser. But from a communication/empathy perspective, this is a terrible response because it makes the merchant feel like you’re not taking their issue seriously. However by the “urgent” subject line and amount of exclamation points, clearly, the merchant is very concerned. And instead of listening to their concerns, you’re invalidating their feelings and basically saying “Calm down. Nothing is wrong.”

So how could a developer respond with the same information, but in a way that makes the merchant feel like you’re taking their concern seriously?

First off, as soon as you get this type of email, immediately respond “I’m on it!” so they know whether you’re looking at the issue and they’re not just sitting there freaking out wondering if you’re even at the computer or taking a nap. 

(As a pro-pet workplace, naps are encouraged at Netalico and the biggest source of nap interruption is urgent emails)

The merchant is probably sitting there thinking: 

"Holy crap, this person can't checkout. Can nobody check out? How many sales are we missing because of this, and how much-paid marketing are we actively losing money with because of this?" 

And maybe they even tried the checkout and it worked for them but that's even more confusing because they can't pinpoint what's going on and you, the developer, are the only person who can help them.

So after you’ve been able to investigate the issue, here’s a better response:

Hey Merchant,

I just did a test order on the checkout and it went through (see screenshot) so there doesn’t seem to be a global issue, but there may be a customer-specific issue that they’re running into. Would it be possible to get a bit more details or a screenshot from customer service so I can try to reproduce it? As soon as I’m able to reproduce it I’ll be able to dig into it a bit more and get to the bottom of it!

 Thank you!

-Developer

 This response can be broken down into this simple formula with the catchy acronym, ARVAR:

 Acknowledge - As soon as possible, let the merchant know you’re looking into it.

  1. Reproduce - Try to reproduce the issue with the information you’re given (which might not be very much).
  2. Validate - If you’re able to reproduce the issue, confirm with the client that you’re seeing the same problem. If you can’t reproduce it, acknowledge that there might still be an issue and provide some proof like a screenshot or order number that you completed a test successfully.
  3. Ask - If you’re not able to reproduce the issue, ask for more details that you think will help you reproduce it. This also helps train clients in the future to give you better information upfront, reducing the back and forth and ultimately being able to solve the issue quicker.
  4. Reassure - Sandwich your response with some reassurance that you’re taking the issue seriously. Especially if you’re not able to reproduce it because otherwise, it can seem like a denial that there’s even a problem.

 

To Be Continued At….  MageX 2019 - Experience Commerce

Come to MageX September 12th and 13th in Austin, TX to hear the full version of this talk where we’ll dive deeper into Developer to Merchant communication and as Merchant to Developer communication as well as hear many more amazing speakers!

Copyright © 2019 MageX