As a maintainer of an open source project there are things that can help to make your role easier. One of them is encouraging useful issues being filed on the project with good information about the problem or suggestion. In this post to his site Sebastian De Deyne shares a few helpful hints on what can make for a good issue.

Maintaining a number of open source projects comes with a number of issues. Reporting a good issue will result in a more engaged approach from project maintainers. Don't forget: there's a human behind every project.

His suggestions include:

• as much detail as possible ("X is broken" isn't useful)
• having a single point or suggestion per issue
• being polite (remember, open source maintainers aren't often paid for this work)

His last point might be the most important: making a human connection. Sometimes it's easy to forget that there's a real person on the other end of the line. If you work with the person reporting the issue rather than just focusing on the technical parts it can make it an easier and more pleasurable process for all involved.

With the GDPR (General Data Protection Regulation) deadline looming on the horizon, there's no better time to make your applications compliant. Christoph Rumpel, a development lead on the Laravel-based Botman chatbot software, as posted a guide to help you ensure your chatbots are compliant.

Only one month left until the GDPR will take effect and people are already freaking out. If you haven't made yourself familiar with this topic, you need to do it now! This article will give you a summary of what you need to know and provide you with steps to make your chatbots GDPR compliant.

His article starts with a brief definition of what GDPR is and what it impacts. He then goes through and lists out some of the key changes that will have to be made to be in compliance including:

• Increased Territorial Scope
• Consent
• Process Personal Data
• Documentation

With those basics out of the way, he gets into the application of them in chatbot software. To make it easier he's come up with a listing of eleven questions to ask or steps to take to get you closer to compliance. For each he briefly describes it and provides some screenshots of the output from the bot that would be compliant.

On the Evozon blog there's a post that provides "a brief reality check to developers about GDPR" and how it effects them and their applications. GDPR (General Data Protection Regulation) is a regulation passed in Europe that enforces certain requirements about personal data and how it should be handled.

If you`re reading this, it means you`ve already heard about it or you`re about to receive some flash-news: there`s a new all-encompassing data privacy regulation in the EU. Ready or not, 25th of May 2018, the date when the General Data Protection Regulation (GDPR) becomes effective, will wait for nobody. If there’s any buzz around it, it`s because of a good reason: businesses will have to comply, software will have to evolve.

While there is still some uncertainty around certain parts, the article goes through some things you can do to help you prepare and make your application compliant including:

• discovering and documenting the purpose of the data that is being collected
• providing clear notification of data collection for the user
• define retention periods and deletion policies
• tracing any changes that happen with the data

The article does a good job providing a "checklist" of sorts you can use to ensure you're compliant. Of course, it's by no means an actual method of compliance but it does provide a good list to guide you in the right direction.

On the Laravel News site there's a recent post by Sharon Steed talking about building a culture of trust and why sharing is good on both a personal and corporate level for your career (and not just in technology).

I speak about empathy on teams and why vulnerability is a great asset in your professional life. Sharing ideas falls right in line with my own ideology, but I also understand why people are so terrified to offer up opinions.

[...] I’m constantly amazed at how many people refuse to talk about projects they are working on for fear of others trying to swipe the idea. I’m even more so surprised at people who go out of their way to not share ideas with bosses or coworkers. Yes, there is absolutely a chance that someone else will take credit for that idea. The nature of working with other people, however, is that of collaboration.

She goes on to give some example situations, how sharing and trust between people plays and role and how many are realizing the value of being open. She gives examples of companies that are following this same idea on a corporate level like Buffer, Zappos and Landmark (an oil and gas software company). She ends the post with some practical advice on how you can help foster this culture of trust in your own company and career.

Matthew Turland has an interesting new post to his site sharing some of his own thoughts on how you can stay employable as a developer with some great suggestions both on the technical and personal side.

Following my post on changing jobs, I communicated with a friend who’s in the market for a job. His circumstances inspired me to write a post for a slightly difference audience. So, here’s some advice on remaining employable as a developer.

His suggestions touch on topics like:

• length of employment at one company (sometimes based on the type of company)
• the balance between being a generalist and fitting only into a niche role
• constant learning (and spending time "off the clock" doing professional development)
• networking with other people

There's a lot of good content in the post so be sure to give it a read, especially if you're a developer that's been in the same role for a while...

Alex Bilbie has an interesting new post to his site looking at the idea of open source guilt. He uses the term to describe the feeling you can get when a project falls by the wayside and you're not putting as much effort into it as you had before. He uses his own real-world project work as an example (an Oauth2 server and client).

I've willingly and happily poured hours of my life into both projects. [...] After leaving the university I moved to London and my life "got flipped-turned upside down" (as Will Smith once put it) which naturally resulted in a reduction in the number of commits that went into the projects. [...] I did my best with the emails piling up in my inbox but I also ignored many. [...] Releasing open source projects is a great feeling however there are a number of considerations one should bear in mind.

He makes the suggestion of four things to keep in mind when working on and releasing an open source project. These are things that can remind you (and keep you away from) some of the issues he's had in his own work:

• Actions have consequences
• People want to help
• Your personal reputation is on the line
• Popular open source projects work well when the authors are using the project regularly themselves

He also includes a few personal things he's going to do to try to make life easier and happier including roadmaps for projects, documenting via FAQs and being more honest about his own availability.

Matt Frost (one of the two hosts on the Loosely Coupled podcast) has a new post to his site about some of his own experiences and advice around avoiding burnout.

Writing software is an incredibly gratifying profession; the idea that you can take a problem and find creative solutions through the use of technology is what drives a lot of us forward. What happens though when the drive is gone? What happens when that nifty little side project, training course, blog post or book goes from being nifty to being a drudgery? I came to this point a number of months ago and stayed there for a while, having now come out of this funk there are some things I learned that I'd like to share.

He talks about some of his own trouble with burnout, the project he was involved in and what it taught him about dealing with it (and life in general). He gives some sensible advice including "don't sit at your desk all day" and "prioritize things". The advice is simple and to the point - avoiding burnout is something only you can do for yourself. Waiting for things to "just get better" isn't going to work.

In his latest post Adam Culp discusses something that developers are all to aware of, whether they will admit it openly or not, is a feeling of anxiety around problems they have, both personal and work/development related.

Yesterday I was approached by a developer, apprentice, friend, and sometimes mentor, who was having some personal issues. I consider this person to be very strong, and capable of great things. [...] During the conversation it was revealed how they’re experiencing HUGE anxiety, complete with panic attacks, and are even consulting a physician who prescribed medication for it. [...It's a] common misconception is that anxiety is caused by the stress of the moment, which is simply not true. [...] For each of us the cause is slightly different, because we each struggle with our own problems and OCDs.

Adam shares some of the common stressors developers can feel around their work and life including not being "busy enough" at work, wanting to contribute but not knowing where to start and loud or open work spaces. He includes a few bits of advice on these things, some from his own experience including how to say "no" to deadlines, talking and sharing with others and doing some kind physical activity. Be sure to check out the comments for thoughts and ideas from other members of the community too.

Often times developers only think about tracking the bugs in the code for their "real jobs" and don't worry about issues that might pop up in their personal projects. Brandon Savage suggests that they should both be important and that not tracking bugs on your personal projects can be a bad thing for the quality of your code.

Too often, it seems like these development practices are abandoned, especially with regards to the use of a bug tracker. I know I have personally been guilty of failing to use a bug tracker, even though I use things like Subversion and develop specifications. It’s easy to forget, but important to remember.

He lists five reasons why you should use a bug tracker for your personal development:

• Our minds are imperfect repositories of information.
• Bad development practices can form.
• It makes it harder to force ourselves to use bug trackers for private paying clients.
• Predicting time to completion becomes more difficult.
• Seeing progress being made is that much more difficult.

There's nothing more telling about the quality of a conference than a personal experience and the Zend Developer Zone has posted one from Jason Austin and Garrison Locke about the ZendCon conference they attended back in 2006 and some of their experiences there.

One day when browsing around the internet Jason came across a posting about the 2006 Zend Conference being held in November. It was billed as "the premiere PHP conference." We asked our manager if there was any way we could attend. If we were going to be "real" PHP developers, we felt like we needed to be at this event – it was the definitive place to be if you were in the PHP world.

They talk about the reality check they got when attending the conference - learning things they'd never heard of before ("fantastic and intensely frightening") in talks like Matthew Weier O'Phinney and Mike Naberenzy's "Best Practices for PHP Development" session.

The article's a good read for anyone considering attending a conference, either ZendCon or any others through out the year.