AltiumLive - BugCrunch

From an early age we have, for the most part, been raised to both fear and loathe bugs. When we see a bug crawling across the floor, we feel both curious and repelled – should we inspect and play with it, or zap it by whatever means possible? Alas, we tend to perform the latter instead of relocating the tiny critter to a safe haven in the back yard!

Fast forward to a stage later in our lives where we routinely operate devices that utilize a host of software-based applications. Be it a mobile phone, a PDA, or a PC, when something doesn't function properly, something 'glitches', or worse, 'crashes', we stifle (or perhaps not) an exclamation of "another bug!".

While its origins may be unclear, the use of the term 'bug' when something doesn't function properly in a software application has become established and almost second nature. Possibly because it conjures the picture of some parasite that stops normal smooth operation.

As the complexity of source code grows, so too does the possibility of encountering one or more 'bugs'. With millions upon millions of lines of source code, Altium Designer is no exception. And each time a change is made to an existing area of the software – to deliver an enhancement or some new functionality – the potential for bugs increases considerably. Testing of new features and regression testing of existing features – performed on an ongoing basis and heightened through the use of Beta Testing – aims to detect and reduce these bugs. Software bugs are truly the type of bugs that should not be relocated, but rather eradicated altogether! But although the holy grail is to release software totally free of bugs, even the most die-hard critic out there will acknowledge (albeit grudgingly) that some of the critters will slip through the net.

When we spot bugs, we aim to crunch them. But of course you spot them too. So we have a process and system as part of the AltiumLive community to report bugs you find for fixing. We have affectionately named this system BugCrunch.

With the BugCrunch system, you have the ability to report bugs for fixing. For each reported bug you will have the opportunity to vote, alongside other community members, to get that bug fixed. While all bugs found in the software should be (and indeed are) logged for resolution, BugCrunch gives you the ability, as a community, to express your feelings about different bugs, and collectively influence the 'fixing priority'. In other words, bugs will get fixed regardless, but with BugCrunch you have a say in which ones jump to the top of the queue. Once a reported bug in the BugCrunch system is passed through to development, a fix is guaranteed. And although a specific timeframe for a fix cannot be given, those bugs accepted for fixing as part of BugCrunch will, through your community efforts, have preferential priority over other bugs, in terms of their resolution.

So break out your bug swatter and bug spray and get BugCrunching!

Accessing BugCrunch

BugCrunch has its very own space within the wider AltiumLive community. Access can be made from anywhere within the AltiumLive site simply by clicking the BugCrunch link at the top of a page.

How it Works

The system is divided over a series of three sub-sections, accessed by clicking on the following links within the BugCrunch banner space:

• New – this is a list of reported bugs that have not yet been assessed and passed through to development. In this section you can comment on, and vote for, the bugs you feel are most important to you, and are passionate about getting fixed.

• In Development – this is a list of bugs that are currently being fixed by Altium's Development Teams for a forthcoming update to Altium Designer. So issues listed here are actively going through the development process.

• Crunched – this is a list of bugs for which Altium's Development Teams have delivered a fix. In other words, they've been 'crunched'!

New Bugs

Clicking the New link gives access to the New section of the system, which lists all reported bugs that have been 'spotted', but have not yet been assessed and passed through to the In Development stage. Bugs are listed 20 per page. Use the page controls available above or below the list to step or jump through pages of reported bugs accordingly. Alternatively, use the search feature (located at the right-hand side of the banner area) to quickly return a shorter list of bugs, relevant to (matching) your supplied search criteria.

Each bug entry is presented with a title and description, along with the name (and image/icon) of the community member reporting the bug, their geographical location (courtesy of a flag), their parent organization, and the date the bug was added to the system. Any tag words added when the bug entry was defined will also be listed – these are used to quickly filter bug reports according to a specifically-clicked tag.

Reporting a New Bug

To report a new bug that you have spotted, simply click the Submit New Bug button. The New Report pop-up window will appear, with the category set ready to "Bugs". Enter a concise summary of the bug in the Title field, followed by a more detailed description, including steps to reproduce the issue. Add also, any tags that will aid searching for this report in the future (see Filtering Reports using Tags). You can also add an attachment to the report, such as an image or a zip of a design project, for example. Should you wish only Altium to be able to see an attachment, rather than the whole AltiumLive community, simply enable the Is Private option.

Once defined, click the Submit button – your new bug will be added to the list of reported bugs. If you decide not to proceed with entering the bug report, simply click the close cross at the top-right of the pop-up window.

Viewing a Specific Bug

Clicking on the title for a bug entry will access the detailed page for that specific bug. The following regions are presented:

• Summary Info – initially identical to that presented for the bug within the parent list view.
• Attachments – displayed if an attachment was added to the bug report, and the Is Private option was disabled. A thumbnail image is provided alongside the name and size of the attachment. You are able to download the attachment and, if applicable, view it in a pop-up window.
• History – reflects key moments in the bug's life as it makes its way through the system. To begin with, there will be an entry for when the bug was submitted, and by whom.
• Who Voted – a collection of profile pictures, reflecting who has voted for the bug. A new bug report will always have at least one vote, that of the originator, which is automatically cast at the time the bug report is submitted.
• Comments – provides a listing of comments added to the report by community members. To add your own comment to a bug report, simply click within the window of the Add New Comment section and type away. Then, commit the comment by clicking the Submit button. Your comment will be added to the bottom of the current list of comments for that bug report.

Editing and Rejecting a Bug

For a bug report that you yourself have originally submitted, the detailed page for that bug will have a couple of extra controls:

Edit – use this control to access the Edit Report pop-up window. You can modify the report's title and description, and add or modify tags as required. You can also change the category for the report, should you realize that it is an idea for adding or enhancing functionality, rather than an issue with current functionality. If you decide not to proceed with modifying the bug report, simply click the close cross at the top-right of the pop-up window.

Reject – use this control if you need to reject the bug report. A pop-up window will appear, in which to select a reason for the rejection. Choose from either "A Duplicate" or "No Longer Valid". You can also add a comment, to further explain the bug's rejection in greater detail.

Voting for a Bug

Next to each bug entry in the list of new bugs (and also to the left of the Summary Info region at the detailed page level) you will notice a me too button. Click this to vote for the bug. Voting for a bug is free. If the passion is truly there to get a bug fixed – if it's a bug that annoys and simply drives you crazy – then casting your vote will help raise that bug's popularity. And the more popular a bug, the more likelihood of it being addressed sooner rather than later!

You can only vote once for any given bug, and this is reflected after casting your vote. The me too button is replaced by the text "You have already voted". This acts as a good visual indicator to see where you've already been, when browsing the pages of new bugs to see where to cast your next strategic vote.

Taking a look at the detailed page for the bug, you will see that your profile picture has been added to the Who Voted region. Again, visual confirmation that your vote has been cast, and a nod to the originator of who is supporting their 'cause'.

How New Bugs are passed into Development

Altium will assess each bug in the New bugs list, after which one of three things will happen:

1. If the bug is something that has been detected already by Altium and scheduled for fixing, or is deemed a more serious bug, then that bug will be accepted for fixing straight away, and will be moved to the In Development section of the system. Note that very serious bugs (or showstoppers) will always be addressed as soon as possible.
    
2. If the bug is verified and reproducible by Altium, it will be passed through to the In Development stage once it is assigned and a developer actively starts working on a fix for it. Bugs that have garnered the most votes are typically passed first, since the community has deemed these more important and therefore first in line to be fixed. However, this may not always be the case, especially if a bug with a lower number of votes can be readily fixed more expediently within the time-frame of the next looming Altium Designer update.
    
3. If, after careful consideration, Altium assesses that the bug is not a valid issue – for example it's not reproducible, or it's a duplicate – or if it's not applicable because that area of software is being redeveloped so specifically fixing it is not necessary, it will not be passed through to the In Development stage. Rather it will be 'rejected'.

Rejected Bugs

Bugs are typically rejected by Altium in accordance with point 3 in the previous section. But they may also be rejected directly by their originators. Either way, an e-mail will be sent automatically to the originator, informing them of the rejection.

Regardless of the source of their rejection, such bug reports will disappear from the New bugs list. They are not, however, deleted. You can still find them using the system's search facility.

The voting information for a rejected bug is replaced with a note stating that either the bug has been rejected by Altium, or it has been rejected by the submitter.

Bug Expiration

The system has built-in rules for ensuring the level of 'bug-noise' is kept to a minimum. These are bugs that have been sat in the system with no activity for a period of 30 days. So nobody is voting on them, or even commenting on them. And if they're not getting attention, and especially if the only vote they carry is that of their original submitters, then it is reasonable to assume they are not popular bugs. Such bugs will be marked as having 'expired'. So if you really want a bug to gain popularity and make it through to development for crunching, generate activity around it, comment on why it should be fixed ahead of other bugs, and above all, cast your votes!

As with rejected bug reports, expired bug reports will disappear from the New bugs list. They are not, however, deleted. You can still find them using the system's search facility.

Expired bugs may well get fixed at some stage, but no promises can be made. Since they didn't gain popularity and yield a swag of votes to be accepted for fixing, they will be fixed according to Altium's schedule (as though they had never passed into the BugCrunch system). In other words, they don't get a 'priority fixing' sticker, as it were. In contrast, those bugs that do get successfully passed through to development will be addressed sooner rather than later, since your voting efforts and enthusiastic activity reflect your collective need to see expedient resolution – the very purpose of the BugCrunch system's existence.

Bugs In Development

Clicking the In Development link gives access to the In Development section of the system. Listed here are those bugs that are actively being addressed by Altium's Development Teams. To put that another way, each bug in this list has been assigned to a developer, who is actively engaged in providing a fix for it.

Taking a look at the detailed page for a specific bug entry shows that the voting information in the Summary Info region has been replaced with a note stating that the 'bug is in development and being fixed by Altium'. In addition, the History region now contains an entry for the date on which the bug was reviewed, and by whom. This is the point in time that Altium has assigned the bug for fixing by a developer.

The list of bugs in this section of the system is essentially the bug-fix (bug crunch) task list for the forthcoming update of Altium Designer. It provides transparency over what bugs are actively being fixed – giving you a heads-up of what to expect in the next update of the software.

Crunched Bugs

Clicking the Crunched link gives access to the Crunched section of the system. This is the 'end of the line' as it were – the final 'resting place' for all true bugs in the system. It is a list of all bugs fixed by Altium's Development Teams.

A Crunched bug is a bug that was accepted for fixing and has been subsequently fixed by Altium. Taking a look at the detailed page for a specific bug entry shows a note added to the left of the Summary Info region, essentially stamping the bug as Fixed. In addition the History region now contains an entry for the date on which the bug was fixed, and by whom (though this is not necessarily the same person that provided the fix!).

Searching Bug Reports

Considering the entire BugCrunch system, and the fact that no bug report is ever deleted, the number of bug reports becomes considerable, and continues to grow. Having to manually wade through pages upon pages of reports, trying to find issues of particular interest becomes a painstakingly-laborious task. To this end, the system has been fitted with a search facility, which can be found at the far right of the BugCrunch banner area.

Simply enter keywords for a search as required, then either press Enter, or click the button. The search facility is case-insensitive and should you wish to search for an exact phrase, simply enclose your search text in quotes (e.g. "map ports to a constraints file").

Searching is across the following report attributes:

• Title

• Description

• Name of the community user reporting the bug.

The matching text is highlighted in yellow.

The Show drop-down field above the results provides a range of filters to further refine the results by category (or current status of a report, if you prefer):

• All – returns all bug and idea reports matching the supplied search criteria, across the entire BugCrunch and Ideas systems.

• New – returns bug and idea reports matching the supplied search criteria, and which are currently sitting in the New section of the system.

• In Development – returns bug and idea reports matching the supplied search criteria, and which are currently sitting in the In Development section of the system These bugs/ideas are actively being fixed/implemented by Altium.

• Crunched/Released – returns bug and idea reports matching the supplied search criteria, and which are currently sitting in the Crunched section of the BugCrunch system, with a status of having been fixed by Altium, or in the Released section of the Ideas system, with a status of having been implemented by Altium.

• Rejected – returns bug and idea reports matching the supplied search criteria, with a status of having been rejected by Altium, or by the original submitter.

• Expired – returns bug reports matching the supplied search criteria, with a status of having expired (no activity within a 30 day period).

 By default, a new search will show matching reports across all categories. In all cases, results are sorted by Date of report submission, with most recent listed first.

Filtering Reports using Tags

Although not part of the scope of the search facility, you can use the tags – assigned to bug reports at the time of their creation – to quickly filter reports. Simply click on a tag and all bug reports possessing that same tag will be grouped together and displayed. To all intents and purposes, this is an additional searching feature.

Again, matching bug reports across all categories will be displayed by default, but you can refine the results by category using the Show drop-down. This functionality is identical to the main search facility.

An Evolving System

BugCrunch is a new way to share experiences and opinions about the future make-up of Altium Design solutions. And, as an organization, it gives you a bigger stake in the software in which you've made an investment, by allowing you to have a say on how that software evolves.

All bugs are taken seriously and all bugs, whether they are reported through BugCrunch or some other mechanism, are logged and put into the development system. Serious bugs are fixed as soon as possible regardless of their status in BugCrunch. Other bugs will be prioritized by Altium in the normal way. What BugCrunch does, is let you decide which of these other bugs you want Altium to put at the top of the priority list – which may not necessarily be the ones Altium would chose to focus on first.

It is hoped that BugCrunch will continue to evolve and mature into a tool to better direct parts of Altium's R&D resources where you, the AltiumLive community, think they should go. Bugs will get fixed regardless, but with BugCrunch you have a say in which ones jump to the top of the queue.