Table of content

• Purpose of the Visual WebGUI Issue tracker
• Visual WebGUI Code Changes
• Creating and Submitting Patch Packs
• Visual WebGui Developers and Approval Process

Purpose of the Visual WebGUI Issue tracker

The Visual WebGUI Issue Tracker (Based on Gemini) is used to track bugs and miscellaneous (documentation) elements that need to be discussed in a permanent, semi-threaded manner and which can more easily store programmatical or textual difference files (Created by "SVN Torstoies") in a manageable way. The issue tracker is there to allow the user community to work on different issues so that the brunt of the work is moved from the shoulders of the small development staff onto the more distributed group.

The primary use of the issue tracker system is to track bugs, where "bug" means anything that causes unexpected or detrimental results in the Visual WebGUI platform. The secondary purpose it is to track some of the miscellaneous issues surrounding Visual WebGUI, such as documentation and commentary.

How to report bugs

The following information is necessary to obtain prior to you submitting a bug properly and in a manner that will get it repaired in the shortest possible time:

1. Bug Description
   The most important information that should appear in a bug report is a clear and simple description (as possible) of the current (wrong) behavior and the expected behavior, and the steps that should be followed in order to reproduce the described behavior.
   
2. SVN revision number
   If this is not the most updated SVN, please make sure you update to get the latest then check the code. The bug may have already been fixed.
   
3. Platform (O/S, Internet Browser)
   Provide the distribution of software you are currently running. Provide the O/S version and the internet browser version (i.e. "Windows XP SP1", "Mozilla Firefox 2.0.0.5")
   
4. Is the problem reliably repeatable?
   If not, you'll need to be EXTREMELY detailed in giving your configuration notes and including as much debug information as you possibly can, as non-repeatable problems tend to be almost impossible to guess resolution types.
   
5. Debugging output
   Include all your outputs from various traces, debugging, etc, as attachments and NOT as pasted text in the bug report.
   
6. Search the bug tracker. Make certain the bug doesn't already exist.
   Please be diligent in reading all of the possibly relevant bugs. This may take some time, but duplication is a real pain. Plus, in reading the other bugs you might find something useful.
   

Visual WebGUI Code Changes

The Visual WebGUI project will open the access to code & the option to submit code changes in two stages:

1. First Stage (Current)
   
   The code will be available from an SVN community branch which will provide the community access to the latest released version's code in read-only mode.
   Code changes proposals could be submitted by mail using patches packs (see "Creating and Submitting Patch Packs") by any VWG registered developer (see "VWG Developers and Approval Process")
   
2. Second stage
   
   The SVN Community branch will enable code changes to members that had passed the Visual WebGUI development team's approval (see "VWG Developers and Approval Process").

Code changes classification

Although valuable code changes are welcome at any time, the VWG project must classify the submitted code change and decide whether it qualifies to the "VWG Major Version", suitable to function as a valid community branch change or unacceptable according to the VWG project's roadmap and development team's measures (see "Code Changes Submission").  The VWG development team will publish the classification of patches and code changes on the VWG Home site.

Getting a Local Copy of VWG Code

Make sure you have TortoiesSVN tools installed (Download) and actively connected to the requested VWG project's community branch.

In order to import the code to your local hard-drive use the SVN Checkout option from the TortoiesSVN shell integration menu:

Then use the Checkout dialog to get the version of code:

Creating and Submitting Patch Packs

As a registered VWG developer, one can submit code changes proposals. In order to submit patch packs of code changes you should follow the instructions bellow:

1. Get the code using the SVN Checkout option from the TortoiseSVN shell integration menu:
   
   
   
2. Choose the desired branch.
   
   
   
3. In case you already have the code, make sure your code is most updated using the SVN Update option from the TortoiseSVN shell integration menu, before you make any changes.
   
   
   
4. Perform your code changes, create a patch file using Create Patch option from the TortoiseSVN shell integration menu and Zip the created patch file in order to make it as small as possible (use standard zip)
   
   
   
5. Submit the code through registered Visual WebGUI site: Code Patch Submission
   

Code Changes Submission

In order to be qualified as a valid code change, your code must be written in the VWG standards (in the nearest future a "VWG Coding Standards" document will be available) and be accompanied with a change trace.

Change Trace

A change trace is a collection of important information that will make it possible for the VWG development team to deal with your code change and classify it. The change trace will be supplied by you within the code submission form


Change Trace fill-up format & sample:

*Developer Name: (The registered developer's name)
Itzik Spitzen

*Project Name: (The name of the project of which this code change relates to)
VWG Major Community Branch

*Change Type: (Bug Fix/Feature/New Module)
Feature

*Issue Number: (Fixing which issue from the Gemini issue tracker, make sure there is one or create a suitable one)

VWG-208

Purpose: (In case of a new feature or module specify the need)
A customer requested to experience Office 2007 look-and-feel

Current Behavior: (In case there is a current relevant state of the issue, specify it here)
Currently supported: XP-like menus and toolbars

*Description: (A description of the expected results, behavior and usage)
The new Office 2007 tabbed toolbar control presents an aggregation
of tools with tabs, which visualizes tools categorization using tabs and
frames.

*Algorithm: (A short description of the algorithm(s) in use or any design pattern if any,
specify "Trivial" if no special techniques were used)

The new control is assembled of the tabs and menu controls XSLs. Internal
layout is based on absolute positioning in order to support Mozilla efficiently.
etc…

Exceptions: (Exceptions and error handling highlights, if any)

Similar Known Behavior: (Win-Forms or any other known sample of the expected behavior)

Office 2007.

Notes:
Make sure you write using the clearest and simplest English language.
Avoid slang in your descriptions.
Use known samples as much as possible.

Documentation
Your code must be well-documented in order to qualify as a valid code change, Please note that when the "VWG Coding Standards" will be published, you should make sure your documentation suites with the basic documentation standards presented by this document.

Testing a patch

After you create a new feature or bug patch submission, it will need to be tested before it can be committed to the SVN repository. By "tested", we mean that multiple persons other than yourself should patch/run/abuse the patch in various manners so that all possible variations of input/output are run through the test. In instances where there are limited test environments, please document exactly how and why you were unable to get others to test the patch so that the developers know that this simply isn't "waiting for testing" and is in fact ready to go. Insufficient testing is a sure way to have your feature put on the back burner - the SVN maintainers don't have time to run exhaustive tests on each new feature. Find people on the Visual WebGUI forum who may be useful/clueful enough to test things for you, and develop a working relationship with other Visual WebGUI users so that you can swap testing routines; this greatly speeds the process. Mail the mailing lists, informing other Visual WebGUI users about your patch and ask for feedback.

Visual WebGui Developers and Approval Process

 The process of signing-up as a registered VWG developer is very easy and simple; the initial process will enable you to gain read-only access to the community branches that are currently available and to submit code changes patches (see "Code Changes Submission").

In order to register, go to: VWG Developer's Registration and follow the signup process.

Online Code Changes – Certified Developer

One of the greatest privileges that can be acquired by a registered developer is the title "Certified Developer". A Certified Developer is entitled of committing online changes in community branches using SVN. This privilege will be available starting from Jan 1st 2008.

Before you can become a "Certified Developer" you must submit sum successful patches that will convince the VWG development team of your readiness to be responsible of committing online changes.

If you feel you are qualified and ready you should apply an application to the development committee at opensource@visualwebgui.com containing the following pieces of information:

1. An updated version of your C.V.
2. A list of previous patches submitted by you.
3. Your arguments: free texted explanation of why you believe that you are qualified to be "Certified Developer" (i.e. special skills, knowledge or other motivations).