Page History

Purpose

This guide, written by Rafael Schloming, gives both Qpid committers and submitters a useful introduction to projecty etiquette, shedding light on how we do things & why. Following this etiquette makes the path to righteousness less long and winding !

Maintainers

...

The Qpid project consists of a number of major components spread across almost as many different languages. Thus it is rare for qpid committers to be experts in every single area of the project.

...

You should use the dev list to reach out to Qpid developers and comment on any JIRAs you're progressing.

Patch Submission

...

As a committer it can be difficult to decide whether/how to provide feedback when someone submits a patch. Often it is tempting to just fix up the patch and avoid the slower and sometimes awkward process of telling someone that they got some part of it wrong.

...

• You need a JIRA for any patch to be attached to, which should accurately describe the change.

Big Ideas

...

Every so often someone has a Big Idea that they get excited about and want to go do. They generally mail the list about it to give people the opportunity to comment, and then when nobody says anything they go off and do it.

Fast forward six months later they commit/merge/enable/publish the result of their Big Idea, and suddenly everyone understands the full implications, and not everyone is happy.

Guidelines

So, here are a few guidelines for making sure this doesn't happen, starting with how to write a good proposal for a Big Idea:

...

• The bigger your idea is, the more time and effort you should spend on the proposal, and ensuring that you get positive responses and deal with the comments and feedback provided in your actual implementation.

Talk early, talk often

No matter how incredibly excellent your proposal is, there is going to need to be some discussion before the result of your Big Idea is blessed. Here are some things you can do to help that discussion go smoothly:

• Make frequent progress reports. Every hour/day/week/month you spend working without telling people what you're doing is an hour/day/week/month of your time that you risk wasting.

• Define milestones and make them visible to the rest of the project. Just like a concrete proof-of-concept can help a proposal, it helps to give people a concrete look at what you're doing while it's in progress. This can go a long way towards avoiding surprises.

And finally .....

When the time does come to commit/merge/enable/publish your Big Idea, it really shouldn't be a surprise to anyone if you've followed the steps up until now, but make sure you let people know in advance by making note in your final few progress reports of when you expect to be finished, and sending a note to the dev list a day or so before you flip the big switch.