A community-based open-source project runs into two forces. On the one hand, you want to be open to accepting as many useful contributions from the community as possible. On the other hand, the users want to be assured of reliable software that allows them to upgrade with minimal fuss. As a practical matter, this means that you have tests to verify that new versions don't break things that used to work, and that you don't include commands that are confusing or inconsistent or likely to change.
When we started the original Web Testing with Ruby project, we accepted anything. But as the Watir project became popular, users resisted incremental improvements when the broke compatibility. As a result, we started to be more picky about accepting contributions that did not have unit tests, that had known bugs or which exposed API's that we thought might be confusing and need to be changed. This has limited the number of people contributing to Watir and has offended some people whose contributions have been rejected. As a result, we are creating two classes of code in Watir. Core Watir will be the solid, well-tested, and moderately well-documented part of Watir. This includes the most popular functionality. We will continue to warrent forward compatibility of this code. Watir Contrib is the second class. This will consist of code that users have found to be useful, but does not meet the full requirements for Watir Core. It may not have unit tests, or have known bugs or limitations. It may lack any documentation. Or it simply may have an API that is inconsistent with the rest of Watir or be too confusing for the introductory Watir user. This code may very well change with new versions of Watir and users may want avoid using it because of this. Users of this code will need to use "require 'watir/contrib/whatever'" to load Watir Contrib code. We will be physically separating these two code bases. Some of the code, currently in 1.4 will be moved into contrib. The Winclicker is probably a good example of something, that, in its current state should be moved. Is it useful? Definitely. Is it hard to use and confusing? Maybe. Does it have unit tests? No. We will also be accepting some recently rejecting code in Watir Contrib. One advantage of this, also, is that we will be able to assess, as a community, whether something is ready to be moved into Watir Core. I've been shouldering this responsibility solo and it has been wearing me out. In particular, i have had one or contributors who have been personally abusive when i've rejected their contributions and i don't enjoy that. In every case, these contributions have clearly been useful. But i've been concerned over whether they would also meet the full expectations that our users have. I want to open up this process and document what further work would need to be done before contributions could be included in core. I suspect that in many cases, we will have one person, say Joe, write the original contribution and then it will get picked up by another, say Ahmed, who will write and tests and documentation for it so that it can be moved to core. Because we did not make this distinction in 1.4, any code from 1.4 that is moved to contrib will continue to work, with little or no change in 1.5. I'm inclined to print a warning, however, so that they understand that this code may change in future releases, and may require different require statements. If there is interest, we can also distribute a version of Watir-core that does not include the contrib code. This might be useful to a test manager or architect who wants to make sure that no contrib code is being used, or who wants to review contrib code usage closely. I expect that this policy will lead to many questions, now and as we implement it. Those are welcome here. However, i would like to move the discussion of specific bits of code and whether they belong to contrib or core to the wtr-development list. Indeed, my hope is that this policy will be encouraging more people to share code that they have written. Bret _______________________________________________ Wtr-general mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-general
