FEATURE REQUEST: Update bug/feature request instructions

[R]

Please either update the bug/feature request instructions to reflect current admin practices, or update your current practices to reflect your own instructions.

The instructions state:

“Make sure the bug (or feature request) you found is not already listed in BPLTrac…”  “Once we acknowledge bugs and features requests, we’ll migrate them to BPLTrac and close the thread in this forum.”

BPLTrac has not been updated in over a year and a half.  I’ve had a couple bug threads acknowledged and closed in recent months with no update to BPLTrac.

If you’ve chosen to stop maintaining your tracking document (which is disappointing), you should remove it from the instructions you ask your users to follow.

[R]

Addendum:

BPLTrac is prominently featured here, as ‘New’.

This too, should be updated.

[Ryan Jordan]

We are indeed changing our tracking system and will update you when we are ready to roll it out. Our release date goal is February 15.

Summary of what’s in-process right now:

• We now use Trello internally for all editorial management, content development, and web development. We have moved “BPLTrac” to a Trello Board, and are using it internally for all issue tracking now. We plan to make this Trello Board publicly available soon, as soon as we work out some internal workflow kinks.
• This forum will still be used to submit bug reports and feature requests, but the format of those requests will change slightly, and we’ll update the instructions accordingly when we roll it out.
• Over the next few weeks, you’ll see most of the open issues on this forum closed, with a message that “this issue has been logged in BPLTrac”, and you’ll then see the status of that issue in our tracking system on Trello when we release it to the public.
• If an issue has NOT been logged in BPLTrac, it means we need more info, validation, repetition, which we’ll note in a forum post in the issue thread.

Here’s the plan for the next few weeks:

1. Log all issues in the new tracking system.
2. Triage, and fix any mission-critical bugs.
3. Prioritize, and assign issues a priority tag of “trivial”, “minor”, “major”, or “critical”.
4. Once there, we’ll release our new system, with a scheduled release date of February 15.

This will offer some additional transparency into what we’re working on at any given time, and how we prioritize website bugs, feature requests, and other internal development projects we’re doing.

Right now, most of our resources between now and February 28 are dedicated to developing and rolling out a new site search engine (major), eliminating the display of email signup forms for users already signed up for the email list (minor), and resolving errors that affect access to online education courses that was disrupted a few weeks ago in a routine update (critical) – and addressing any other membership-specific critical issues that need triage along the way.

[idester]

FWIW, I’d do away with the ‘trivial’ designation, just use minor, major and critical. From a user perspective, calling a bug report or feature request posted by a member ‘trivial’ isn’t a ‘good look’, IMO. Minor I can understand, but calling it trivial can be insulting.

Editor’s note: The “trivial” designation is not meant to be offensive – it’s actually a pretty standard term in web maintenance and dev, and is there primarily so our developers know that this is an issue of the lowest priority and urgency. We’re opting to roll with these industry standards with this terminology. ^rj

[Ryan Jordan]

The new BPLTrac is now available.

See the first post above for details, and visit BPLTrac to learn more.

[Author]

Posts