Using PR to share your patches on BuddyPress Trac

Thanks to Dion Hulse (@dd32), it’s now easier to share patch directly from your BuddyPress GitHub fork to a specific BuddyPress Trac ticket 🙌. It’s a great improvement and I believe it can potentially attract more people to contribute to BuddyPress code.

How does it work?

First if you haven’t created your BuddyPress fork on GitHub, log in to your GitHub account, head over to the https://github.com/buddypress/buddypress.git repository and click on the “Fork” button !

You’ll get a new repository on your GitHub account to work from to contribute to BuddyPress, here’s mine for instance: https://github.com/imath/buddypress.git

Clone it locally, create a new branch to add your changes, commit and push your changes on your branch, go to your fork’s page on GitHub and click on the link to create a Pull Request. You’ll be directed to the page where you’ll be able to link your PR to an existing BuddyPress Trac ticket.

Find the <!-- insert a link to the BuddyPress Trac ticket here --> text and replace it with the Trac Ticket link, for example https://buddypress.trac.wordpress.org/ticket/8647. Of course, if the ticket doesn’t exist yet, you can always create a new one from there.

NB: BuddyPress core committers, do not merge PRs from the BuddyPress GitHub repository, the feature’s goal is to ease code review, we still need to commit changes from our SVN repository.

Click on the “Create pull request” green button and go to your BuddyPress Trac ticket’s page.

As shown in the above screenshot, your pull request will be included into the “Pull Requests” section of the corresponding Trac Ticket. From there BuddyPress contributors can enjoy the GitHub code review features clicking on the View PR’s link or get the patch using the “View patch” link.

To get more information about this feature which is also available on the WordPress Trac, you can read this documentation page of the WordPress Contributor’s handbook.

Getting the most out of this feature

As you may have noticed, we also have some information about automatic checks applied to pull requests. We currently haven’t set these from a GitHub action, but it would be interesting to include PHP Unit tests and why not WordPress code standards checks, see #7228.

#github, #trac

I have renamed BuddyPress Trac’s…

I have renamed BuddyPress Trac’s “Future Release” milestone to “Awaiting Contributions”, because realistically that’s what any of those tickets need in order for them to get done. I have also created an “Up Next” milestone, to try to solve the problem of contributors perpetually adding “interesting” tickets into the next major release’s milestone, without perhaps committing to work on them (I’ve been guilty of this myself on numerous occasions!).

Back in 2016, I published some ideas to try to improve milestone/workflow management. Some small improvements came out of that good discussion.

With the milestone renamed, the workflow for tickets is now, in this order of progression:

1) Awaiting Review: all new tickets start here, awaiting an initial response and triage.
2) Under Consideration: is where new tickets are placed, while we evaluate them and gather further feedback and comment.
3) Awaiting Contributions: is where accepted tickets are placed. They should have consensus and enough detail for someone new to the project to understand and work on.
4) Up Next: is a new milestone, that will contain interesting tickets that contributors have expressed in working on within the next two releases (e.g. half a year, or so).
5) Number major/minor releases: these milestones track tickets that a contributor has committed to working on for that release.

Tickets will be demoted backwards into “Awaiting Contributions” if for some reason they are moved to a more active milestone but never completed.

I hope this makes sense; we’re very limited by the ticket organisation/planning tools we have in Trac, but once we get used to this, I think it will give everyone a better understanding of what will probably be happening in the next half-year’s worth of BuddyPress releases.

I am aware that renaming “Future Release” has not solved any problems associated with that “graveyard” milestone; I have an upcoming discussion post with some ideas for improvements.

Happy to hear feedback; easy to rename or adjust course if that’s what our consensus is.

#3-0, #trac, #workflow

We had a discussion in…

We had a discussion in our Slack channel recently (logs here) about how we use Trac, focusing around tickets and milestones. This morning, I was inspired to think about how we use Trac, and put some suggestions forward for ideas we could consider. I’m sharing them here to start a discussion and see what everyone else thinks.

(In the following, I’m defining “milestone” as a version number, e.g. 2.2 or 2.3. “Future Release” and “Awaiting Review” are special milestones and what follows isn’t meant to apply to them.)

Problems

1. Tickets are often punted from one release to the next, then to the next release, then to the next release, and so on — because no-one wants to work on them. Yet at some point, we felt they were important and are reluctant to close them.
2. It’s impossible to look at a milestone report and easily understand which tickets are planned for the next release (or are realistically achieveable).
3. Future Release is a graveyard where old tickets go and die, rather than a holding area for tickets yet to be assigned to the next milestone.

Ideas to fix this

Moving tickets to a milestone

If you move a ticket to a milestone, you are accepting the responsibility to get that task done for the next release.

• You must maintain an active presence on the ticket by monitoring it for new discussion or any changes, and responding promptly.
• You must keep the rest of the project up-to-date with the progress on your ticket. It’s preferred that this update is made at least every 2 weeks, in either: a dev chat meeting, a post on the bpdevel blog, or as a new comment on the ticket.

Generally, a person should not be responsible for more than 2 unfinished tickets in a milestone at any given time. Estimating time is hard, and real life is full of unexpected demands on one’s time, which are more important. 🙂

Tidy up the Future Release milestone

Let’s audit all tickets in the Future Release milestone. If a ticket has not been updated in over 1 year?, close it as “maybelater”.

Closing tickets does not mean the project will never implement the suggestions, but it will help to de-clutter our workflow and return the Future Release milestone to being a list of actionable “patchless things that are not scheduled for the next release”. I think this feels like a hard idea but is something we need to do.

We’ll need to do this on a periodic basis; maybe 2 or 3 times a year (looking for the “needs-patch” keyword).

Managing new contributions

Tickets should never be moved directly from a milestone to another (“punted”). If a ticket fails to make a release, and if we still want to implement it in a future version, then it is moved back to Future Release.

New tickets with patches (often bug fixes)

• Will be moved to the Future Release milestone, with the “has-patch” keyword.
• Remain in Future Release until the patch has been reviewed and is ready to commit (therefore being “sponsored” by the reviewer for inclusion in the next release).

New tickets without patches (often enhancement ideas)

• Remain in Awaiting Review until the idea is fully explored. It needs to be detailed enough so it is ready for a contributer to start working on.
• If the exploration takes some time, assign a new “in-review” keyword.
• Once the idea is ready and it has been decided that the project would benefit from having it included, move the ticket to Future Release with the “needs-patch” keyword.

Trac reports

Most of the existing Trac reports were copied from WP’s Trac a few years ago. My feeling is that most of them aren’t useful for us. Let’s remove them all, and build the following reports to match our workflow:

• All tickets waiting review
• All tickets in review
• Future Release tickets needing a patch
• Future Release tickets with a patch
• Tickets in the next major milestone
• Tickets in the next major milestone, grouped by Owner (i.e. the person who set the milestone).

I just want to make clear these are my own ideas which I’m sharing for discussion. Maybe nothing will come of them, but it would be nice to try something different for the 2.3 cycle.

#trac #workflow

Moved closed tickets out of Future Release…

Moved closed tickets out of “Future Release” and into their correct milestones. Going forward let’s make sure all closed tickets are in a non-floating milestone.

Now that we have workflow keywords and all the same goodies, I’m also going through and aligning our trac with the WordPress core trac. We can do a better job of using Trac reports to keep an eye on scope creep in the future.

#trac

BuddyPress Trac got a bit of a facelift…

BuddyPress Trac got a bit of a facelift today to bring it in line with core Trac. You now have ticket severities, keyword management, Gravatar support, a fresh coat of paint (and logo), and After the Deadline support. You’ll also see a notice when creating a ticket, and will be forced to preview it. When uploading an attachment, you’ll be explicitly granting its use. Probably some other goodies too.

Let me know if there are any bugs. The color could probably use a tweak as it’s used on so much text, which we can do next week.

#trac