eclipsecon topten

Eclipse Top Ten: #2 Say no so others say yes

When I first starting working on eclipse, I quickly realized that I have to say no a lot. I only have a couple hundred bugs in my bucket. Not many compared to some of my committer friends.

I have a friend.  Let’s call him Paul. He has about 1300 bugs assigned to him in the Eclipse 3.x stream. He can solve 20-30 bugs a milestone. Each milestone is six weeks.  That’s excellent fix rate.  So thousands of bugs. Can’t fix them all. We’ll never have a zero bug count.

In the beginning, I would close bugs with something like “Sorry, I’ll never have time to fix this”.  This isn’t a way to win new friends in the community.  I’ve learned that the way you say no makes a difference.   You need to say no in a way that will make others say yes.    How do you do that?

For instance, say I’m spending a lot of time working on a plan item for 3.6M7.  I really don’t have time to fix a new bug that a member of the community has just opened in my bucket.  But, I can be helpful and give them pointers to where the code needs to be changed.

Here’s the repository location of the code.  Here are the JUnit tests.  I can offer to provide guidance, but you need to take ownership of this problem if you want to get it fixed.  Taking ownership means transparency.  People will be watching you.  This community grows by letting others to step up to the plate.

Previous Eclipse Top Ten posts
1

2 comments on “Eclipse Top Ten: #2 Say no so others say yes

  1. Kim, how is the ratio between bugs and new feature-request ?

    I assume they are treated differently, right ?

    Bugs can be fixed also by others while new features needs to be discussed first (or how is that processed ?)

    thanks and kind regards,
    Berni.

    Like

  2. Berni,

    I'm not sure of the numbers on bugs vs. feature requests. I don't track that myself. Everything is a bug to me 🙂

    This is the way I prioritize my work
    1) Build is broken
    2) Others can't work (I need to implement a features for other committers so they make progress.
    3) Plan items
    4) Everything else

    I have seen new features implemented by contributors so I don't think this a barrier. The main roadblock to getting more bugs fixed is people. We'd like more contributors and committers 🙂

    Hope this helps!

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: