Specific instructions for providing software review feedback

Steps to take each time you review or test ebase software:


  • If you're testing ebase software, log in to your copy of ebase and note its release date. If you're not sure you have the latest release, look at the software downloads page to see if a newer release of your software is available, and install the latest release if you don't have it already. This way, you won't be observing bugs that have already been fixed or asking for features that have already been added.
  • Log in to your Bugzilla and ebase.org accounts—each in its own browser window—so that you'll be able to add content/comments to either location as needed.
  • If there are specific features you want to review, look in the documentation area for the software you're reviewing to see what other reviewers have noted about these features already. Check Bugzilla to see if bugs in these features remain unresolved or have been fixed but need confirmation by a tester. These initial steps will help you make the best use of your time, learning from previous reviews' work and focusing on aspects of the software that are not yet throughly reviewed.
    If the features you want to review do not yet appear in the documentation for your version of ebase, you can add the feature you're reviewing to the documentation (see below).
  • As you review ebase, submit observations (bug reports or feature requests) to Bugzilla (see below).
  • Submit additions & revisions to the documentation section of this web site (instructions below). You can also post comments (instructions below) to any documentation page or Bugzilla report; all sincere questions & observations are welcome!
  • For each feature you test, please report both positive (works as expected) and negative (bug apparently not fixed) test results. Without your positive results, we won't know when we've tested enough. Without your negative results, we won't know where more work is needed.

    Here's an example:
    I tested my ability to create new staff logins (user accounts) in ebase. I found one method that works fine, and documented it here. I also noticed that another method, which used to work, appears to be unfinished... so I filed a bug report on it.
  • [coming soon: link to page describing how you can migrate data from your own ebase install for use in testing.]

    draft comments

    2nd bullet) 1. log into both bugzilla and ebase accounts at the same time? 2. I am assuming if the bugs are unresolved we comment on them and if they are already resolved we don't?

    3rd bullet) How do I know if the features list is incomplete? Does that just mean I add features I "want" to see on my version of ebase, or features I have seen and used, but have been left off the feature list somehow?

    Helpful questions

    I've made some revisions in response to your questions. Let me know how it looks now?

    We'd like the documentation to reflect the software as it is now, in use... But we don't currently have a complete list of _existing_ ebase features, so there will be features to add to the documentation that are already in the software.

    New features (not yet in the software) can be discussed generally on the developers' listserv and planned/tracked minutely in Bugzilla. Once a new feature is added to the software, we'll need documentation for it on the ebase web site. Is that clear?
    One more clarification: each time the software is changed, its version is changed as well. This way we can communicate clearly about versions for purposes of testing & user support. New features are never added to a specific version, but rather released in a new version.

    For example, if the current version of ebase is ebase 2.8 build 090624 (the June 24, 2009 build of ebase 2.Cool, I might add or change a feature today and release the results as a new version called ebase 2.8 build 090701. If I indicate in Bugzilla that a feature was introduced or changed on July 1, 2009, users will need to install a July 1 or later version to see that new feature.

    Maybe I should have a little page on versions, explaining this for all?

    changes and versions

    It's a bit clearer now. Let me see if I understand correctly. If I am reviewing the version of ebase to use with Filemaker 8.5 (the one we have) and find that something doesn't work right, I'll go to Bugzilla and search for the feature that isn't working. If I find it listed, I'll know someone else has already come across it and I'll just move on to the next feature. If it's not listed then I'll make a bug report. I don't really need to worry if it's been fixed or not right? Just that there is a bug report.
    I'm a little less clear on the documentation part. If I am reviewing a feature that has not been listed in the documentation, am I actually writing a description of how to use it? Instructions for the manual? Or just my observations. For example, adding a payment to one of the records works just lovely. Good work guys kind of comment?

    It might help to have an example in these instructions. I always find that to help me...

    I think it's a good idea to have a little page explaining versions and features - I did not know that was how it was done.

    Example posted

    If you find a bug and it's already been reported, it's actually helpful to know that you confirmed the bug. You can add a comment to the bug report stating your confirmation, and add specifics about how you reproduced the bug if your steps were any different from those detailed in the bug report.

    Similarly, if you see that a bug report says a problem has been fixed but the bug is still "open," it means that we're waiting for verification. If your testing confirms that the bug is fixed, please add a comment to that effect so we can close the bug report with more confidence.

    In theory there's a risk of us getting too much information in Bugzilla, but for now more is better!

    As for adding documentation, anything you can contribute is better than nothing. Even just a blank page with a title describing a feature that needs to be documented is great. Off-the-cuff observations are fine; someone can come along later and edit them into more formal documentation. Praise is welcome too, but maybe on Bugzilla or the developers discussion email list rather than in the documentation section of the web site.

    I've added pages specifically describing how to contribute bug reports and documentation, and I've also added a sample of each, linked from the text above.



    Comment viewing options

    Select your preferred way to display the comments and click "Save settings" to activate your changes.