Author: Tom (Page 298 of 434)

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.

Continue reading

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.

Continue reading

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

When I threw the WordPress Plugin Boilerplate up on GitHub a couple of years ago, it was merely meant to be a place for me to share how I [used to] start off most of my plugin-specific projects.

Sure, it’s changed over time (as things do as we gain more experience), but it’s also grown into something that’s received a number of contributions both of which are around ideas for what should or shouldn’t go into the plugin, as well as a variety of pull requests to solve issues – some defined, some not – all from very generous people.

What started off as a small personal project, has grown into a project – although that I still consider small – has a significant enough level of interest and activity that I’ve had to introduce a little bit of project management into maintaining it.

This was obviously something I never set out to do, but it’s something that’s become necessary. So with that said, I thought I’d do a short series on what I’ve learned about open source project management.

Over the next few posts, I’ll cover an idea or two that I’ve learned – at least thus far – that I believe to be cornerstones in open source project management.

Continue reading