Request: Could we have a Logos Bug Tracker?
To the Logos team:
Now that the Logos 'community' is more effectively engaged than ever before, could you help us further by creating a bug tracker style site? There are obviously many bugs with Logos 4, and although many of them are minor, they do all need attention. Unfortunately with the volume of support questions, and arguments about L3, there is a real danger that you'll miss out on bug reports.
The community seem to be very happy to track down bugs, and evaluate them to see whether they can be repeated. That info could be very valuable to your programmers if it could be done in a controlled manner. It would also help everyone if they saw that bug reports were taken seriously and acted upon, as I know many of them are.
How about it?
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
Comments
-
This is a great idea for two reasons:
1. it keeps "negative talk" to one place, so there won't be so many threads about problems.
2. It would drastically help with repeat posts about the same issues with the same bugs being reported several times.
A big +1 from me.
0 -
Mark Barnes said:
there is a real danger that you'll miss out on bug reports.
I get this sense too.
Mark Barnes said:That info could be very valuable to your programmers if it could be done in a controlled manner.
While I'm sure that the Logos techs already use a bug tracker, it would be good if this were in the public domain.
I've often visited the Chrome bug tracker to see if problems I am encountering have been reported (every time yes)
Mark Barnes said:It would also help everyone if they saw that bug reports were taken seriously and acted upon, as I know many of them are.
Agreed
0 -
This might be worth an affirmative triple negative with a negative confirmation eg. a bug tracker is definitely not not uncommon but highly unlikely (for those that have seen Bradley's double negatives before).
Dave
===Windows 11 & Android 13
0 -
Grace & Peace,
Bill
MSI GF63 8RD, I-7 8850H, 32GB RAM, 1TB SSD, 2TB HDD, NVIDIA GTX 1050Max
iPhone 12 Pro Max 512Gb
iPad 9th Gen iOS 15.6, 256GB0 -
Mark Barnes said:
To the Logos team:
Now that the Logos 'community' is more effectively engaged than ever before, could you help us further by creating a bug tracker style site? There are obviously many bugs with Logos 4, and although many of them are minor, they do all need attention. Unfortunately with the volume of support questions, and arguments about L3, there is a real danger that you'll miss out on bug reports.
The community seem to be very happy to track down bugs, and evaluate them to see whether they can be repeated. That info could be very valuable to your programmers if it could be done in a controlled manner. It would also help everyone if they saw that bug reports were taken seriously and acted upon, as I know many of them are.
How about it?
Hi Mark,
This Beta forum is the place to report bugs on the current beta being tested. If you want to be sure to track particular threads, check the "Email me replies to this post" box before posting. It has been helpful to have the 'Bug' headings, or as in this thread's case, a 'Request' heading, so both Logos and customers can more easily find threads with bug reports, suggestions, etc. We monitor the beta forum (and main forum), and report bugs in our internal bug database for tracking. We will generally post fixes within the original thread or in the next beta's release notes.
Thanks,
Melissa0 -
What about all the bugs in SR-7?
0 -
Michael Lyman said:
What about all the bugs in SR-7?
Possible bugs in a current version can be reported in the main Logos 4 forum or by emailing logos4feedback@logos.com. That email address is on the "Report a problem" page accessible from the Help menu in Logos 4 (http://www.logos.com/support/reportaproblem). Forums are helpful because a customer can sometimes find out on the forum that a bug has already been reported, or that there is a workaround, or that the function, by design, does not work the way they expect.
Melissa
0 -
Melissa Snyder said:
This Beta forum is the place to report bugs on the current beta being tested. If you want to be sure to track particular threads, check the "Email me replies to this post" box before posting. It has been helpful to have the 'Bug' headings, or as in this thread's case, a 'Request' heading, so both Logos and customers can more easily find threads with bug reports, suggestions, etc. We monitor the beta forum (and main forum), and report bugs in our internal bug database for tracking. We will generally post fixes within the original thread or in the next beta's release notes.
Melissa,
Thanks for taking the time to reply. Unfortunately many of us don't believe the forum is adequate - at least not without some clear direction. I reported a bug (this one, reported in the beta forum a week ago). No-one knows what's happened to that report. I suspect it's been ignored. I posted a log, so the crash can be verified. But other users don't have a problem. I'd expect therefore to be asked "What Bible's do you have prioritised?". Or perhaps the crash was caused by an indexing bug, and therefore is not a bug, but a symptom of a bug. But I have no idea. Here's another example, reported nearly a month ago. Again, there's no response from Logos. And that makes me much less likely to submit bug reports in the future.
Bug-tracking software would enable other forum users to tag the report as "duplicated" or "not-an-issue-for-me" or "duplicate of xxxx bug", or "not-a-bug" or whatever. That means less work for you. But then you also could tag bug reports: "evaluating" "wont-fix", "accepted", "resolved". So that means we know where we are up to. We (the users) gain because it makes Logos more accountable and communicative. You gain because you get all of us testing instead of you having to do it. It really is win-win.
Please reconsider,
Mark
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Mark Barnes said:
Thanks for taking the time to reply. Unfortunately many of us don't believe the forum is adequate
Mark Barnes said:Please reconsider
[Y] +1
Grace & Peace,
Bill
MSI GF63 8RD, I-7 8850H, 32GB RAM, 1TB SSD, 2TB HDD, NVIDIA GTX 1050Max
iPhone 12 Pro Max 512Gb
iPad 9th Gen iOS 15.6, 256GB0 -
Mark Barnes said:
Unfortunately many of us don't believe the forum is adequate - at least not without some clear direction
I have to agree...posting problems without a response is frustrating and has made me do it less.
MacBook Pro (2019), ThinkPad E540
0 -
Melissa Snyder said:
Possible bugs in a current version can be reported in the main Logos 4 forum or by emailing logos4feedback@logos.com.
The problem is that no one likes reporting into a "black hole" - either logos4feedback or (mainly power users) the existing forum (non-)structure. Most users are happy to post in the existing forums because it has become a culture and has been encouraged by CS! The power user responding to that may determine that it is a bug and responds in the "hope" that it will be detected and reported to the developers. So give us (power users) a "secret" BUG forum with special functionality that will benefit our responses in the main forum and also benefit Logos. A big win-win!
Dave
===Windows 11 & Android 13
0 -
Another option would be to add a page on the wiki, which linked to forum posts containing confirmed or likely bugs. However, this would be a reasonable amount of work, and is only of value if it is actually used by Logos staff, who then committed to responding to posts which were added to the wiki. How about it Logos?
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Dave Hooton said:
"black hole"
It does certainly feel a bit like a black hole. There is far less interaction by Logos people on these forums now that at any time previously. As the number of threads increases, the likelihood of every single problem being noted/addressed decreases.
Dave Hooton said:the existing forum (non-)structure
I've been trying to think of a forum for a software program that doesn't include a place to record bugs (for those without a dedicated bug-tracker). It seems highly inefficient to just mix everything in together.
0 -
I'd be ok (not ecstatic, but would stop complaining) if they even created another sub-forum into which Logos only could post, & then copy into it the posts that they've verified as inputs into their internal bug tracker. That way, they retain privacy (wish they wouldn't) of their internal bug tracker (in the absence of any Logos-supplied rationale for not exposing it, I'm free to suspect it might be related to minimizing thier exposure to product liability). But copying stuff we already gave them also gives us explicit feedback on which posts made it into their bug database.
Best of all, the opportunity to post gives me a boost on my way to the 10k prize... LOL
Bill
Grace & Peace,
Bill
MSI GF63 8RD, I-7 8850H, 32GB RAM, 1TB SSD, 2TB HDD, NVIDIA GTX 1050Max
iPhone 12 Pro Max 512Gb
iPad 9th Gen iOS 15.6, 256GB0 -
Damian McGrath said:Dave Hooton said:
"black hole"
It does certainly feel a bit like a black hole. There is far less interaction by Logos people on these forums now that at any time previously. As the number of threads increases, the likelihood of every single problem being noted/addressed decreases.
Don't tell Bob about this...
(Yes, I know you posted your comment yesterday. [:)])
Damian McGrath said:Dave Hooton said:the existing forum (non-)structure
I've been trying to think of a forum for a software program that doesn't include a place to record bugs (for those without a dedicated bug-tracker). It seems highly inefficient to just mix everything in together.
Our current bug tracking system is designed for small teams, not public submission. It can expose a public interface, but it doesn't even allow searching of cases submitted by other non-logged-in users (probably because it's designed to support teams with many clients, and being able to see another client's bug could divulge sensitive information). So we'd probably have to purchase and/or set up a different system, then integrate the two on our end, which would be a bit of work. I'll talk to Bob, but I think I know what he's going to say... [:)]
0 -
Bradley,
Since your return to the forums you have been heroically responding to threads.
Thank you.
This sort of interaction has been missing and is sorely needed.
0 -
Bradley Grainger said:Damian McGrath said:Dave Hooton said:
the existing forum (non-)structure
I've been trying to think of a forum for a software program that doesn't include a place to record bugs (for those without a dedicated bug-tracker). It seems highly inefficient to just mix everything in together.
Our current bug tracking system is designed for small teams, not public submission. It can expose a public interface, but it doesn't even allow searching of cases submitted by other non-logged-in users (probably because it's designed to support teams with many clients, and being able to see another client's bug could divulge sensitive information). So we'd probably have to purchase and/or set up a different system, then integrate the two on our end, which would be a bit of work. I'll talk to Bob, but I think I know what he's going to say...
Bradley, my point was that even if we don't have other software we should have a sub-forum for bugs....
0 -
Bradley, we appreciate very much your input. I understand that you probably can't expose your bug-tracker to us. But what we're suggesting as significant benefits for Logos staff. This is what forum members are offering:
- Screening bug reports, filtering out feature requests and human-errors.
- Removing or tagging duplicate reports.
- Asking for more information or logs as appropriate.
- Testing bug reports to see if they can be duplicated.
- Tagging or copy valid reports so that Logos staff can see them easily.
In return, we're asking:
- Logos staff regularly review these valid bug reports (perhaps daily or at least twice a week).
- Logos staff acknowledge the report and respond briefly: "fix requested", "minor issue so not a priority", etc.
- Logos staff update the report when a fix is released.
As I see it, that puts more work on us, and means less work than currently for you. We'd be prepared to do it because (a) We want the bugs fixed more quickly!, and (b) It will give us confidence that our hard work is worthwhile because it will be improving the product for thousands.
We don't necessarily need commercial grade bug-reporting software (although there's no reason why one of us couldn't install something on a personal server). The most important thing would be that if users came up with a proposal that would work, Logos would commit themselves to being involved and regularly reviewing and reporting.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Mark Barnes said:
We don't necessarily need commercial grade bug-reporting software (although there's no reason why one of us couldn't install something on a personal server). The most important thing would be that if users came up with a proposal that would work, Logos would commit themselves to being involved and regularly reviewing and reporting.
I was thinking about this and was wondering if semantic tags on pages at wiki.logos.com might give sufficient searching capability. (If I get time, I'll play around with it and see if a workable page can be constructed. If so, a fairly simple template for a new bug report should be able to be produced. The full text search capability of the Logos wiki engine seems adequate for this purpose, and the semantic tags mean that automatically created tables of bugs (i.e., DB queries) can be very easily constructed. It might be a little more structured and manageable than a special sub-forum, though not as powerful as a dedicated bug-tracking system.)
0 -
Bradley Grainger said:
I was thinking about this and was wondering if semantic tags on pages at wiki.logos.com might give sufficient searching capability.
I just threw something together very quickly: http://wiki.logos.com/Logos_4_Bugs
As you can see, it has a dynamic query ability, and the basic fields are defined for sorting/searching. Simple full text searching (e.g., http://wiki.logos.com/search.aspx?q=bug+highlighting) also works. Useful? Usable? Too much? Not enough?
You're right: it will be much more efficient for me to scan through the list of "pending" bugs than to read every forum post. This might really be win-win. [:)]
0 -
Well, it's not the easiest method. But, it may work if we can get people behind it.
I've added my latest
0 -
I'll add mine and give it a go...
0 -
Ooh, I like that. Very clever.
I don't mind if it's not 'easy' to use, so long as it's efficient. Perceived complexity can often act as a quality control in online communities.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
I've started to add links to my bug reports. I think the system works well. But I wonder if we should have a milestone field for those times when Logos staff say "this has been fixed in the forthcoming version out next week", or "we're hoping this will be fixed in 4.1".
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Bradley Grainger said:
I just threw something together very quickly: http://wiki.logos.com/Logos_4_Bugs
As you can see, it has a dynamic query ability, and the basic fields are defined for sorting/searching. Simple full text searching (e.g., http://wiki.logos.com/search.aspx?q=bug+highlighting) also works. Useful? Usable? Too much? Not enough?
You're right: it will be much more efficient for me to scan through the list of "pending" bugs than to read every forum post. This might really be win-win.
Is Logos going to be responsible for updating the status? Or do we need to when a Logos employee confirms the bug?
MacBook Pro (2019), ThinkPad E540
0 -
Damian McGrath said:
Since your return to the forums you have been heroically responding to threads.
Aw, shucks. (As they say here. Or so I've heard.) I'm sorry if I came across as fishing for compliments; that wasn't my intention. I just wanted to point out that it wasn't all doom and gloom. [;)]
0 -
Mark Barnes said:
I've started to add links to my bug reports. I think the system works well. But I wonder if we should have a milestone field for those times when Logos staff say "this has been fixed in the forthcoming version out next week", or "we're hoping this will be fixed in 4.1".
Yes, I agree that adding a "fixed for" (or similar) field would probably be good. Of course, there's the times where we might mark it as fixed for Beta 9, and then that gets renamed to RC 1, but that should only be a minor inconvenience. Too bad there's no global search and replace...
0 -
Todd Phillips said:
Is Logos going to be responsible for updating the status? Or do we need to when a Logos employee confirms the bug?
We'll see how it goes, but I imagine that we'll change it once we reproduce the bug and log it internally. But feel free to keep setting the status to "confirmed" for the existing bugs that we've already told you we have reproduced.
0 -
Bradley Grainger said:
Too bad there's no global search and replace...
Not in the wiki itself; but there's always search and replace for whoever has direct access to the database underpinning the site! That's just a simple SQL query [:)]
0 -
Bradley Grainger said:
Yes, I agree that adding a "fixed for" (or similar) field would probably be good. Of course, there's the times where we might mark it as fixed for Beta 9, and then that gets renamed to RC 1, but that should only be a minor inconvenience. Too bad there's no global search and replace...
Wouldn't that just go in the status field?
After release, wouldn't that entry be deleted?
0 -
Bradley Grainger said:
Aw, shucks. (As they say here. Or so I've heard.) I'm sorry if I came across as fishing for compliments; that wasn't my intention. I just wanted to point out that it wasn't all doom and gloom.
I don't think you came across as fishing for compliments - and I'll never give one if it's fished for!
Notice that many of the threads to which you responded have gone unanswered for many days, even over a week. Critical bugs were not recorded with the release notes (esp. wrt merging indexes).
It's certainly not doom and gloom but it has been a "black hole." So, I'm grateful that you're back on board.
0 -
Bradley Grainger said:
We'll see how it goes, but I imagine that we'll change it once we reproduce the bug and log it internally. But feel free to keep setting the status to "confirmed" for the existing bugs that we've already told you we have reproduced.
I would hope Bradley that you (or whoever from Logos) would take it on board to mark bugs as confirmed and fixed. The bug tracker will only work if there is proper quality control.
0 -
-
Bradley,
I agree there has been a "black hole" but there's a ton of light in it now. Thanks. I suspect/hope Bob gave you a well-deserved break, but it is good to have you back. If he didn't (give you a break) I'm sure you've been busy making things better somewhere else than in these forums. We depend on a reasonable amount of interaction with Logos folk to keep us going around here -- we're a bunch of Pavlov's dogs - at least that's what some people's avatars indicate (Phil??) and need you to ring the bell once in a while.
Thanks for the long list of things you did today.
Chris
0 -
Chris Elford said:
I suspect/hope Bob gave you a well-deserved break, but it is good to have you back. If he didn't (give you a break) I'm sure you've been busy making things better somewhere else than in these forums.
Bob's sent me on a couple of trips recently: first to SBL in New Orleans, and then to the first Logos 4 Camp Logos in TN. So it hasn't been a complete break from work, but it's been fun; I've been able to meet a number of forum users and put faces to avatars. On the minus side, I think I've forgotten how to code... it's been so long... [;)]
0 -
steve clark said:
It might help if you could sticky this to the top of this forum for those who haven't seen this thread yet.
Good idea; done.
0 -
Bradley,
Over in another post, http://community.logos.com/forums/p/6672/51839.aspx#51839 I just ruminated if we should make putting a log into the original forum post a standard feature/requirement of a bug report so that you get the info you need about the process/system/setup etc. you need to find a problem?
I also asked there if "non-repro" reports are helpful or just fluff posts?
Chris
0 -
Chris Elford said:
Over in another post, http://community.logos.com/forums/p/6672/51839.aspx#51839 I just ruminated if we should make putting a log into the original forum post a standard feature/requirement of a bug report so that you get the info you need about the process/system/setup etc. you need to find a problem?
I also asked there if "non-repro" reports are helpful or just fluff posts?
Non-repro reports are helpful; any information you can provide about what is different about your system (OS, video card, resources, memory, etc.) can help narrow down what causes the problem.
Log files are almost always useful for crash reports, but usually not so useful for bug reports of unexpected (non-crashing) behaviour. In those cases, screenshots are usually better. But if you have the log files and can take a few seconds to attach them, it doesn't hurt.
0 -
Bradley Grainger said:steve clark said:
It might help if you could sticky this to the top of this forum for those who haven't seen this thread yet.
Good idea; done.
The information on this thread re the bugtracker appears on the second page.
It would be better to create a locked sticky with this information:
1) How to post a thread on a bug: with the word BUG in the title and with a description of the problem and the specs of the computer being used, etc.
2) How to add a bug report to the Wiki
3) A link to the wiki page on Diagnostic Logging in case logging is required (or a full description on enabling Logging).
0 -
Bradley Grainger said:Chris Elford said:
Over in another post, http://community.logos.com/forums/p/6672/51839.aspx#51839 I just ruminated if we should make putting a log into the original forum post a standard feature/requirement of a bug report so that you get the info you need about the process/system/setup etc. you need to find a problem?
I also asked there if "non-repro" reports are helpful or just fluff posts?
Non-repro reports are helpful; any information you can provide about what is different about your system (OS, video card, resources, memory, etc.) can help narrow down what causes the problem.
Log files are almost always useful for crash reports, but usually not so useful for bug reports of unexpected (non-crashing) behaviour. In those cases, screenshots are usually better. But if you have the log files and can take a few seconds to attach them, it doesn't hurt.
Thanks for that clarification, Bradley.
I don't want to be accused of fluffy posting!
Chris
0 -
Bradley Grainger said:
I just threw something together very quickly: http://wiki.logos.com/Logos_4_Bugs
As you can see, it has a dynamic query ability, and the basic fields are defined for sorting/searching. Simple full text searching (e.g., http://wiki.logos.com/search.aspx?q=bug+highlighting) also works. Useful? Usable? Too much? Not enough?
Thank you, Bradley! This is great. I stumbled upon it before finding this thread on the forum and at first was puzzled/annoyed, because it seemed all these bug reports were cluttering up the "All Pages" view (now you have to scroll down a bit to see some of the other significant pages). I thought the wiki should be used mainly for "how-to" stuff. But I see this is a great system, so thanks for taking the time to set it up.
Another idea I'd had for bug tracking was setting up a Logos page on GetSatisfaction. I've been beta testing another product which uses it for their public bug tracking system, and it works pretty well (though they have a much less involved user community than Logos does).
0 -
Bradley Grainger said:
I just threw something together very quickly: http://wiki.logos.com/Logos_4_Bugs
As you can see, it has a dynamic query ability, and the basic fields are defined for sorting/searching. Simple full text searching (e.g., http://wiki.logos.com/search.aspx?q=bug+highlighting) also works. Useful? Usable? Too much? Not enough?
Thank you, Bradley!
Bill
Grace & Peace,
Bill
MSI GF63 8RD, I-7 8850H, 32GB RAM, 1TB SSD, 2TB HDD, NVIDIA GTX 1050Max
iPhone 12 Pro Max 512Gb
iPad 9th Gen iOS 15.6, 256GB0 -
Damian McGrath said:
It would be better to create a locked sticky with this information:
1) How to post a thread on a bug: with the word BUG in the title and with a description of the problem and the specs of the computer being used, etc.
2) How to add a bug report to the Wiki
3) A link to the wiki page on Diagnostic Logging in case logging is required (or a full description on enabling Logging).
I've stumbled around the wiki bug recorder and come up with some suggestions:
1. I don't think everybody should be allowed to add a bug report because there will be many spurious reports that somebody will have to monitor and possibly remove.
2. Not everybody should be expected to do so, either. Many users just want to report a problem or difficulty without caring that it is a bug, then having to decide if it already exists, etc.
3. So the power users should be the ones to create bug reports from the forum + their own; which means the first one handling a post should report it under their name (not the actual user!) and encourage the posting of any logs or images and make a statement to the effect that it has been reported on the wiki. That way everyone is informed (OK, I put up a report in Todd's name, but I knew he'd get around to it[:D]).
4. We still have other bugs to put in, and it's imperative we do so to make this work properly, avoiding future "black holes" (and MVP's need to work for their status!).
Dave
===Windows 11 & Android 13
0 -
Personally, I'm finding after <2 days the bug tracker is great; we can see that bugs have been acknowledged and reproduced and some already fixed! Much better than waiting around for the next release to see what happens [:)]
Bradley, can we have an extra column on the front page - 'date added' and sort by that by default with new additions coming to the top? Just a thought...
0 -
Jon Rumble said:
Personally, I'm finding after <2 days the bug tracker is great; we can see that bugs have been acknowledged and reproduced and some already fixed! Much better than waiting around for the next release to see what happens
Bradley, can we have an extra column on the front page - 'date added' and sort by that by default with new additions coming to the top? Just a thought...
I agree about its facility, and I've seen Bradley actively working it!
Good suggestion, too.
Dave
===Windows 11 & Android 13
0 -
Can I suggest a couple of changes to the Bug Tracker:
- The addition of a 'severity' field. Some bugs are minor, but others are critical. It would help if we could flag up which were most important.
- Better sorting. It's already difficult to keep track of everything. It would make most sense if pending and confirmed bugs went to the top, or even were listed in a separate table.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Also it might be very useful to either add a column for date the bug was first reported and/or date the bug report was last edited and provide the ability to sort this field.
By the way, nice job Bradley, this provides a much needed point of contact for issues. Had you considered Eventum as a bug tracking system? Free and I have implemented it for both large and small projects running on both Windows and Unix servers. While it does not do some things I would like it does a lot. Including reports for management
0 -
Jon Rumble said:
Bradley, can we have an extra column on the front page - 'date added' and sort by that by default with new additions coming to the top? Just a thought...
I don't think the wiki search engine supports automatically returning the created date of the page (though that would be useful). I added a new search to show only bugs that have not been linked up by me or someone else at Logos: http://wiki.logos.com/Logos_4_Bugs#New_Bugs
(We could require posters to manually type in the date when they add a bug, but that seems like unnecessary work.)
0 -
Mark Barnes said:
Can I suggest a couple of changes to the Bug Tracker:
- The addition of a 'severity' field. Some bugs are minor, but others are critical. It would help if we could flag up which were most important.
- Better sorting. It's already difficult to keep track of everything. It would make most sense if pending and confirmed bugs went to the top, or even were listed in a separate table.
Any new field can be added with the [[field name::data]] syntax in the wiki page. (Or {{?set field name::value}} if you don't want it to be visible.) Then add "|?field name" to the query at http://wiki.logos.com/Logos_4_Bugs to display that field. Once the page is displayed, the field headers can be clicked to re-sort (but the wiki engine doesn't currently support automatically sorting by anything other than title or last revision date.)
0 -
James W Bennett said:
By the way, nice job Bradley, this provides a much needed point of contact for issues. Had you considered Eventum as a bug tracking system? Free and I have implemented it for both large and small projects running on both Windows and Unix servers. While it does not do some things I would like it does a lot. Including reports for management
I haven't looked at any bug tracking systems yet; I know there are a lot of open source and hosted options out there, and I don't have time right now to examine even a small fraction of them. To some degree, I consider this an experiment: if it's obviously providing value, but running into some fundamental limitations of our wiki engine, we'll need to consider moving it to a "real" bug tracking database.
0
