Author: Tom (Page 292 of 429)

Starting 2014

January 3, 2014 / Tom / 0 Comments

For many of us who write regularly, it’s hard to fight the urge not to write about what we did last year, what we plan to do this year, and how we’re going to accomplish it.

Though I don’t typically write those types of posts, I absolutely dig reading them for others primarily because:

I think that I follow a lot of really interesting people who are doing a lot of really interesting things,
It’s inspirational to see what others have achieved,
It’s fun to see what’s coming in the next year from said people and watch them make it (or even scrap it!)

And sure, I have my own goals and things that I plan, but I’ve been at this long enough to know that I do best when I forecast for the short term – that is, for the next quarter or so – and then make detailed lists for the given month on what I’d like to accomplish.

Sometimes, items carry over from the previous month; most of the time, the list of full of new things to check off.

In an attempt to cover what I’m planning to achieve in the first part of 2014 (read: January), I thought I’d go ahead and share a couple of notes specifically related to WordPress work – both from a personal stand point and from Pressware’s standpoint.

What I’ve Learned About Open Source Project Management: Releases

January 1, 2014 / Tom / 0 Comments

This is the fifth and final part in a series on What I've Learned About Open Source Project Management.

Though some may argue, I think that all projects – open source or not – ultimately culminate in releases. That is to say that when it comes to building software, your ultimate goal is to provide a solution for your users that gracefully solves their problem.

I think all developers strive for kaizen in their work, but because of our own nature, we end up shipping things that sometimes feel like a step back, sometimes introduce more bugs, or sometimes simply dissatisfy the user.

Of course, that’s only one side of the story, right?

On the other hand, companies and developers do often ship incremental improvements of their software much to the delight of their users. And though that’s not always the case, it’s something for which we all should aim.

Everything that’s been covered in this series leads up and contributes to releases.

How this works in closed source software may or may not be the same as it works within the confines of open source project management – I’d venture to say that there’s overlap – but nonetheless, here are my takeaways with respect to aiming for releases in open source project.

What I’ve Learned About Open Source Project Management: Pull Requests

December 31, 2013 / Tom / 0 Comments

This is part four in a series on What I've Learned About Open Source Project Management.

One of the nicest things about working with open source projects is when you – as a project maintainer – receive a pull request (or a patch) for source code on which you’ve been working.

Just like it feels, say, to get the first comment on your blog, getting your first pull request is exciting because it means that someone took the time to look at the project, perhaps browse the issues, and then contribute code to help improve your work.

But over time, you may end up getting a number of pull requests, some of which – although always appreciated – may detract from the initial vision and mission of the project.

At this point, it’s up to you to determine how to best handle these requests.

What I’ve Learned About Open Source Project Management: Issues

December 30, 2013 / Tom / 0 Comments

This is part three in a series on What I've Learned About Open Source Project Management.

Over the course of my time on working on a number of different open source projects, I’ve learned several things that contribute to open source project management.

In this series, I’m covering those things within the context of the WordPress Plugin Boilerplate; however, the things mentioned in this series are not specific only to that project, nor are they things that I think are prescriptive for every project.

They are things that I’ve learned and things that I’ve found to be successful. This may change over time.

Nonetheless, a number of these ideas are likely common in team-based environments, but working in open source with team members who are volunteering their time is an entirely different beast.

Up to this point, I’ve covered ideas such as the project’s vision, mission, and milestones.

In this post, I’m going to be talking specifically about issues – not bugs, not defects, not hot fixes – but issues.

What I’ve Learned About Open Source Project Management: Milestones

December 27, 2013 / Tom / 0 Comments

This is part two in a series on What I've Learned About Open Source Project Management.

In this series of posts, I’m discussing a bit about what I’ve learned regarding open source project management, specifically through the context of the WordPress Plugin Boilerplate.

The thing is, a number of these lessons are relatively commonplace in any team-oriented environment; however, when you’re working in the open source culture with an unofficial distributed team, there are nuances to the work that aren’t always as easy to manage as they are when it comes to running projects in a face-to-face environment.

In the last article, I talked a little bit about vision and mission as they relate to running projects for yourself, for a distributed team, or even potentially for a organization of some type.

This article is going to focus on something that’s all too familiar with respect to software development: milestones.

But just as others have written about content in the past (and will continue to write about it in the future), I think it’s something worth sharing today – at least with respect to my own experience – in open source project management.