Strategic Decision

This method is pretty self explanatory. Plain Black's development team is constantly researching new features that have potential to make WebGUI more powerful as an application platform and as a content management system. Generally speaking, this development is still largely influenced by customer demand and about the only time it's not is when it's an architectural change necessary to facilitate maintainability and growth in the core. A good example of this was getting rid of global sessions during the 6.x development cycle. The change was necessary to allow WebGUI to continue growing.

Fund a feature

Fund a feature is a method to sponsor the development of a feature you would like to see in WebGUI. There are several benefits to fund a feature -vs- contract development

The feature will be supported as a part of WebGUI and survive upgrades (See Note Below)
The feature will be implemented in the next feature release of WebGUI in most cases.
We offer discounts for features that will be put in the core because they benefit everyone.

NOTE: Most contract development projects will survive upgrades as most everything in WebGUI is pluggable and our API is guaranteed to be backwards compatible until at least the Fall of 2009.

Non-Pluggable:

WebGUI Operations (The icons you see in the admin console)
SPECTRE modules. (A custom workflow engine for example)

Pluggable:

Authentication Modules
Workflow Activities
Assets and Wobjects
Macros
Utility Scripts
Language Modules
Help and Documentation

Now, it's important to realize that just because you're willing to pay to have a feature put in WebGUI doesn't necessarily mean it will be approved for inclusion into the core. The feature has to be useful to WebGUI and the community as a whole. For example, a specialized authentication module that ties into your companies proprietary directory service is not going to be in the core. If a feature isn't suitable for the core, Plain Black can still help you through contract development.

RFE - request for enhancement

An RFE can be submitted by clicking on the RFE link of the Plain Black Support page. When you submit an RFE there is a lifecycle it goes through.

Someone submits a feature idea via the RFE list
Plain Black is notified of the submission, reviews it to determine if it is suitable for inclusion in the core
If Plain Black will not accept the RFE we will add a comment explaining why and CLOSE the RFE
If it is accepted, we will assign a Karma Factor to the featue. This factor represents a very quick time estimate as to how long it will take a developer to code the feature, test it, and document it.

At this point, there are two ways that the feature can make it into the WebGUI Core, Karma Rank and Submitting a patch:

Karma Rank

For every feature release of WebGUI, Plain Black will implement as many of the RFEs on the list as possible. At a minimum, the top ranked RFE will always be added. We start with the highest ranked RFE and move down the list in order of Karma Rank. RFE's are ranked as follows:

Community members transfer Karma points they have earned for participating in the WebGUI community to an RFE.
The number of points transferred is then divided by the Karma Factor which results in a Karma Rank. For example if we estimate a Karma Factor of 10, and you transfer 10 karma points to that RFE, the RFE will have its Karma Rank increased by 1 point.

Submit a patch

The other way an approved RFE can get into the core is if you or someone else writes the code to make it happen. When you're done, you should package your patch and attach it as a reply to the RFE. Finally, you need to email the WebGUI Developers list to have your patch reviewed.

When writing a patch, you need to consider the WebGUI Development Best Practices and Code Submission Guidelines. You should also consider the performance implications your patch has on WebGUI. This can be done by evaluating the impact of your patch with a utility such as ab (apache benchmark) and other means. If you have questions on how the feature should be implemented, the correct plan of attack, etc. EMAIL THE DEV LIST. That's what we're there for! We will be more than happy to guide you and help you make decisions. This is to your benefit because we can save you from having to redo a lot of work due to poor design decisions or failure to consider other problems your patch would produce.

If you submit a patch and there is negative feedback, corrections, suggestions, etc. Don't take it personally. Everyone on the list is very busy and our answers are sometimes short, always direct and to the point. This can invoke an emotional response when you just spent 50 hours of hard work on a patch. The rule of thumb is this:

Assume the person replying is trying to HELP you and means well. ( this is trademarked by Colin Kuskie btw =) )

Email is a horrible way to communicate. You can't hear a persons tone of voice, see their facial expressions, etc. This generally results in a lot of extra effort when writing an email to make it clear that you are being nice and well intentioned. This is wasteful and no one has time for it. So, follow the rule, don't take it personally. Make a person work very hard to let you know that they are being a jerk in an email by assuming the best.

Another thing to know, is that if an RFE is on the list after a week, it's generally a good indication that it's been approved. You still need to have your patch approved though, always. Email the dev list if your not sure whether or not it's ok to implement an RFE.

Writing it yourself

Please refer to Code Submission Guidelines and WebGUI Development Best Practices for more information.

Keywords: core criteria development