From bret at pettichord.com Sun Sep 10 03:20:25 2006 From: bret at pettichord.com (Bret Pettichord) Date: Sun, 10 Sep 2006 02:20:25 -0500 Subject: [Wtr-core] Half-baked code Message-ID: Greetings. This email addresses ideas on how to handle half-baked code. Half-baked code is code that is useful, but unfinished. It may have bugs, require unit tests, or need documentation. And it may have APIs that are subject to change in the future. The current Watir code base contains a mix of well-baked and half-baked code. In my view, we need to separate the half-baked code so that users know when they are using half-baked code. And we need to be more open to accepting half-baked code from contributors. The best of example of half-baked code in Watir is our code to support popup dialogs. The Winclicker is the most commonly used library for this, although some use AutoIt or Wet's dialog support. It is unclear to me that any of these approaches is clearly superior and I've successfully avoiding having to deal with these dialogs in my professional work, so i've never really been motivated to do a complete technical analysis. It would be nice for us simply to develop some solid support for this, but until that happens it would be good if our users weren't given the impression that Watir contained a complete solution. Another example of half-baked code, to pick on myself, is the code i recently contributed in "watir/close_all". This has no unit tests and i'm now aware of some fairly serious bugs in it. I wrote it in the process of building a general framework for a specific application at DataCert and did have some tests for it in that context, but those of course aren't public. Another example of half-baked code was, in my view, Paul's recent mention of code that allows you to say that you want to select the first element (with a certain specified attribute) in the page after another particular element (also specified by attribute). Well, i haven't seen his code, but we had some different opinions regarding what the interface to this functionality should look like. In my view, we need a place to easily share this kind of code publicly and get feedback on it, and try out different ideas before we commit to any particular interface. We need a place that welcomes half-baked code so that we can then work together to bake it. I have one more example. A contributor sent me a bunch of patches that i thought showed promise but needed more work (and tests). I granted him commit rights so that we could work together on a branch containing this code. I eventually merged some of this code to trunk. He was offended that more wasn't taken and eventually took it on himself to commit both some of this half-baked code as well as some other dangerous code that ended up seriously destabilizing Watir, as i had feared. (I intend to finish cleaning up this mess this next week.) He no longer has commit rights, but this whole episode underlines the need to have a clear process for allowing contributors to share half-baked code, publicly, without granting them commit rights. My proposal is that create a separate directory under the watir directory to contain half-baked code. Thus instead of 'require "watir/close_all"' you would do require 'require "watir/experimental/close_all"'. I don't know whether to call this directory 'experimental', 'contrib' or maybe just 'half-baked'. I'd appreciate comments and suggestions on this point. There was a time when all of Web Testing with Ruby was half-baked. It was a rude shock when I came to realize that serious resistance would come from our community to further changes to any of our interfaces, and one of my reactions to this was to be very picky about accepting new methods. Once we became popular, it became clear that our interfaces were commitments, and it was no longer enough to simply ask whether the code was useful. We also had to ask whether we would commit to continuing to support it going forward. Frankly, relaxing these standards will lead to significant user dissatisfaction, but maintaining them has been wearing me out and i feel like i'm jumping from one issue to another without getting much really settled. That's why i want to create a new category for stuff that is useful, but half-baked. To make this work, we do need to have people start delivering their code as stand alone code, rather than direct patches to watir. Many are already doing this. And i wrote an article yesterday describing how to do this: http://www.io.com/~wazmo/blog/archives/2006_07.html#000240 Can this work? Can we explain this to the larger community? Bret -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060910/ed056adc/attachment-0001.html From sy1234 at gmail.com Sun Sep 10 08:40:44 2006 From: sy1234 at gmail.com (Sy Ali) Date: Sun, 10 Sep 2006 07:40:44 -0500 Subject: [Wtr-core] Half-baked code In-Reply-To: References: Message-ID: <1e55af990609100540s628a8e98g306d9cecb780f4c2@mail.gmail.com> On 9/10/06, Bret Pettichord wrote: > To make this work, we do need to have people start delivering their > code as stand alone code, rather than direct patches to watir. > > Can this work? Can we explain this to the larger community? It seems like average Watir users might do better a classic "stable" branch and "testing" branch. The stable branch has all the fully-baked code, and has a solidified API. The testing branch has various userbase contributions either in the code or (preferably easily!) available as separate packages. * Make it known that there will be a cataclysm, as code is moved from stable into availability only in the testing branch. Tell people that features are going to be removed from stability until tests can ensure that they are 100% trusted. * Make it known that all features in the testing branch are open for debate and change. Say that this allows for real-world improvements without needing to commit to early decisions which may turn out to not be the most effective method, later on. * Appologize to the heavy users of the testing featureset. These people are committed enough that they'll realise the value in doing things the right way. They'll probably follow the testing branch. * Anyone who is harmed by these changes is free to continue using what they've been using all along, and when their required features are officially brought forth into the stable branch, then they can switch to that and update their code to use the official methods. * If there is a way to document how people's code will change from testing to testing release, that would be invaluable to many. * Tell people who are users of the testing branch that they should consider themselves required to keep up on the mailing list. Seriously consider making a separate "testers" mailing list. * The goings-on in the testing branch are what drives the official roadmap for the stable branch. As with other projects, many users will be very interested to know what's on the horizon. I'd say it's easiest to make very tough decisions as fast as possible.. to "pull the bandage quickly". Try to give the impression that serious thought has been invested, and that this heralds a new era in the seriousness of the development and future of Watir. Just an idea.. From charley.baker at gmail.com Sun Sep 10 23:45:40 2006 From: charley.baker at gmail.com (Charley Baker) Date: Sun, 10 Sep 2006 21:45:40 -0600 Subject: [Wtr-core] Half-baked code In-Reply-To: <1e55af990609100540s628a8e98g306d9cecb780f4c2@mail.gmail.com> References: <1e55af990609100540s628a8e98g306d9cecb780f4c2@mail.gmail.com> Message-ID: On 9/10/06, Sy Ali wrote: > > On 9/10/06, Bret Pettichord wrote: > > To make this work, we do need to have people start delivering their > > code as stand alone code, rather than direct patches to watir. > > > > Can this work? Can we explain this to the larger community? > > It seems like average Watir users might do better a classic "stable" > branch and "testing" branch. We already have a stable and development version. I'd just as soon keep the core of Watir in these two areas which seems to be working conceptually for most people on the general mailing list. For any additional addons, it makes sense to explain how to inject code to extend out Watir. I'll work on that. The stable branch has all the fully-baked code, and has a solidified API. > > The testing branch has various userbase contributions either in the > code or (preferably easily!) available as separate packages. > > * Make it known that there will be a cataclysm, as code is moved from > stable into availability only in the testing branch. Tell people that > features are going to be removed from stability until tests can ensure > that they are 100% trusted. A contrib directory along with a script to include or instructions on the load path in order to load the contributions makes most sense to me, I'm still a bit hazy about how best this would work among general users. I don't like the idea of a testing "branch", but rather an easy way to incorporate user contribs via a contrib directory, two choices: - we package all the contribs up into a loaded directory - user chooses files to download into a loaded directory I'd opt for the second choice, whoever is using user contribs needs to know that these are separate and not supported by the larger community. Ideally they should be supported by the people who wrote them on the wiki. Before any user contrib is added to the main branch, it must have unit tests. A new category should be added to jira for contributions. * Make it known that all features in the testing branch are open for > debate and change. Say that this allows for real-world improvements > without needing to commit to early decisions which may turn out to not > be the most effective method, later on. User contribs have their own wiki area and are open for debate/improvement/jira issues until there's a consensus that they should be added into the Watir core. * Appologize to the heavy users of the testing featureset. These > people are committed enough that they'll realise the value in doing > things the right way. They'll probably follow the testing branch. This is an unsupported user contribution area. If there are issues or feature suggestions, then they should be added to Jira. No reason to apologize, rather solicit responses, input and additional help. * Anyone who is harmed by these changes is free to continue using what > they've been using all along, and when their required features are > officially brought forth into the stable branch, then they can switch > to that and update their code to use the official methods. > > * If there is a way to document how people's code will change from > testing to testing release, that would be invaluable to many. Agreed, documentation is important, rdocs are easy to create and should be pushed for user additions, before contribs are accepted they should be documented and tested. The current docs also need to be updated. * Tell people who are users of the testing branch that they should > consider themselves required to keep up on the mailing list. > Seriously consider making a separate "testers" mailing list. Doesn't make sense to me to add a new mailing list. Posts about the user contribs will most likely come back to this list or a few people will post on the wiki. * The goings-on in the testing branch are what drives the official > roadmap for the stable branch. As with other projects, many users > will be very interested to know what's on the horizon. It would be great if people actively jumped in to help out with the issues that are reported against the current version. It's also a very good idea that people be able to inject additional functionality into the current version they're using. The "official" roadmap should be an aggregation of some of the user contribs, jira issues and the ideas that are documented in jira through ideas on this list and other inputs. -Charley -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060910/13b63cb4/attachment.html From sy1234 at gmail.com Mon Sep 11 06:01:33 2006 From: sy1234 at gmail.com (Sy Ali) Date: Mon, 11 Sep 2006 05:01:33 -0500 Subject: [Wtr-core] Half-baked code In-Reply-To: References: <1e55af990609100540s628a8e98g306d9cecb780f4c2@mail.gmail.com> Message-ID: <1e55af990609110301u54417ed6p2ef786da846bfe4c@mail.gmail.com> On 9/10/06, Charley Baker wrote: > A contrib directory along with a script to include or instructions on the > load path in order to load the contributions makes most sense to me, I'm > still a bit hazy about how best this would work among general users. I don't > like the idea of a testing "branch", but rather an easy way to incorporate > user contribs via a contrib directory, two choices: > > we package all the contribs up into a loaded directory > user chooses files to download into a loaded directoryI'd opt for the second > choice, whoever is using user contribs needs to know that these are separate > and not supported by the larger community. Ideally they should be supported > by the people who wrote them on the wiki. Before any user contrib is added > to the main branch, it must have unit tests. A new category should be added > to jira for contributions. Being able to dynamically load/include user scripts from a user script repository is a really cool idea. As long as there's a simple way to add/remove or enable/disable user scripts -- since watir has many young programmers -- it would probably go over quite well. Have any other projects done something similar to this? From tester.paul at gmail.com Mon Sep 11 10:34:04 2006 From: tester.paul at gmail.com (Paul Carvalho) Date: Mon, 11 Sep 2006 10:34:04 -0400 Subject: [Wtr-core] Half-baked code In-Reply-To: <1e55af990609110301u54417ed6p2ef786da846bfe4c@mail.gmail.com> References: <1e55af990609100540s628a8e98g306d9cecb780f4c2@mail.gmail.com> <1e55af990609110301u54417ed6p2ef786da846bfe4c@mail.gmail.com> Message-ID: <37c405480609110734h2bb877c6sb7e5ee51d41a02a@mail.gmail.com> Hi there. I can't speak to other Ruby projects, but I can share an experience from a company I worked at nearly a decade ago. I worked at Waterloo Maple Inc (http://www.maplesoft.com/) a while back and tested the main Maple package. I offer the story here as an anecdote because I think it's relevant. If you're not familiar with it, Maple is a math/calculus programming environment where you can feed it equations and it will solve them for you. (Useful to University students and Engineering firms mostly.) It had two basic interfaces: Command Line and GUI. The Command Line module was a direct interface to the math engine and we had a team of PhD's who were responsible for the testing scripts that ensured the math worked as expected. The GUI test team, of which I was a part, was responsible for testing everything else. There was a lot in the GUI to cover so we also had an ongoing Beta program to manage real-usage feedback from professors and engineers all over the world. Here's the relevant part. In addition to the main program CD, there was a bonus "Shared" CD that was included. On this CD was a few hundred extra scripts and programs written in the Maple scripting language that would demonstrate the many cool features that you could do with the GUI program. (Let me tell you.. there were some pretty cool things in those scripts.) During the Maple installation process, the user was asked/prompted to install the Shared CD if they wanted. Totally optional. However, the "Shared" CD contents, while provided with the box that you paid for, was not officially supported by Maple. Each script was copyright by the script author and the user was encouraged to contact the script author directly if they had any questions, comments, or bug fixes to report. I believe that we also had the 'Shared' scripts on an FTP site somewhere so the authors could update their scripts for a subsequent release and users could check to see if there was an update to their particular script of interest. As a Maple user, if you wanted to include any of the shared scripts you simply had to navigate to the correct folder and pick the one you wanted. We, the formal QA/test team, were off the hook for testing these scripts (thank God!), but let me tell you that many of them were really handy when it came time to regression testing! So my two cents on this thread is that I also think it is a good idea to include the half-baked code with Watir. I'm in favour of calling the folder 'contrib' or 'shared' rather than 'experimental'. The scripts should have a standard header format that identifies the author/contributor, script version number (or date), and a simple disclaimer of some sort that directs the user to the author or the Wtr-general mailing list if they have any questions/comments/bugs to share. Heck, we could probably even set up a new wiki or mailing list specifically for discussing the half-baked/shared script contributions if there's interest in keeping that separate. (I don't know that we need to, but I'm just throwing the idea out there.) Hope this helps. Cheers. Paul Carvalho On 11/09/06, Sy Ali wrote: > > On 9/10/06, Charley Baker wrote: > > A contrib directory along with a script to include or instructions on > the > > load path in order to load the contributions makes most sense to me, I'm > > still a bit hazy about how best this would work among general users. I > don't > > like the idea of a testing "branch", but rather an easy way to > incorporate > > user contribs via a contrib directory, two choices: > > > > we package all the contribs up into a loaded directory > > user chooses files to download into a loaded directoryI'd opt for the > second > > choice, whoever is using user contribs needs to know that these are > separate > > and not supported by the larger community. Ideally they should be > supported > > by the people who wrote them on the wiki. Before any user contrib is > added > > to the main branch, it must have unit tests. A new category should be > added > > to jira for contributions. > > Being able to dynamically load/include user scripts from a user script > repository is a really cool idea. As long as there's a simple way to > add/remove or enable/disable user scripts -- since watir has many > young programmers -- it would probably go over quite well. > > Have any other projects done something similar to this? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060911/dd2886ba/attachment-0001.html From bret at pettichord.com Mon Sep 11 12:09:46 2006 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 11 Sep 2006 11:09:46 -0500 Subject: [Wtr-core] Fwd: Consultant recommendations? In-Reply-To: <28d5af770609110809y1d5850f8ya010acbfda7041fb@mail.gmail.com> References: <28d5af770609110809y1d5850f8ya010acbfda7041fb@mail.gmail.com> Message-ID: Anyone interested in helping this guy? I think he's in Northern California. Bret ---------- Forwarded message ---------- From: Chris .Rasch Date: Sep 11, 2006 10:09 AM Subject: Consultant recommendations? To: bret at pettichord.com Hi Brett, Thanks for writing and maintaining Watir! I've played with it to some extent (login to our website) and I like it very much. . I would very much like to use Watir as the foundation of our website's automated testing suite ( http://www.marketocracy.com). However, I need to persuade our management staff that it's worth investing in Watir, rather than an off the shelf commercial package, such as Eggplant. It would help my case if I had some working test code. Unfortunately, our site heavily uses javascript menus for navigation. You can see the menu by logging into a sample account (login: "trasch", password: "m"). I'm a bit overwhelmed by the apparent complexity of getting some working Watir code that can navigate these menus. Therefore, I would like to hire someone to help me get the scripts written. I have a budget of $500, which would come out of my own pocket. (At least initially -- if I can persuade our management staff to go with Watir, then I can probably get re-imbursed for it). Note that I'm not looking for someone to write the scripts themselves, but rather to advise me on how to do it. I also plan to put my scripts up on my blog ( http://crasch.livejournal.com) so that others can learn from them. I realize that you're not doing consulting any more. However, is there anyone else you would recommend that contact? Or any suggestions for how I should best spend the money? Thanks for any help. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060911/02633b94/attachment.html From bret at pettichord.com Mon Sep 11 12:39:01 2006 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 11 Sep 2006 11:39:01 -0500 Subject: [Wtr-core] Half-baked code In-Reply-To: <37c405480609110734h2bb877c6sb7e5ee51d41a02a@mail.gmail.com> References: <1e55af990609100540s628a8e98g306d9cecb780f4c2@mail.gmail.com> <1e55af990609110301u54417ed6p2ef786da846bfe4c@mail.gmail.com> <37c405480609110734h2bb877c6sb7e5ee51d41a02a@mail.gmail.com> Message-ID: This is a good example of what i'm hoping to achieve. Perhaps you can share this story with wtr-general when we announce the plan there. On 9/11/06, Paul Carvalho wrote: > > Hi there. I can't speak to other Ruby projects, but I can share an > experience from a company I worked at nearly a decade ago. I worked at > Waterloo Maple Inc (http://www.maplesoft.com/ ) a while back and tested > the main Maple package. I offer the story here as an anecdote because I > think it's relevant. > > If you're not familiar with it, Maple is a math/calculus programming > environment where you can feed it equations and it will solve them for you. > (Useful to University students and Engineering firms mostly.) It had two > basic interfaces: Command Line and GUI. The Command Line module was a > direct interface to the math engine and we had a team of PhD's who were > responsible for the testing scripts that ensured the math worked as > expected. The GUI test team, of which I was a part, was responsible for > testing everything else. There was a lot in the GUI to cover so we also had > an ongoing Beta program to manage real-usage feedback from professors and > engineers all over the world. > > Here's the relevant part. In addition to the main program CD, there was a > bonus "Shared" CD that was included. On this CD was a few hundred extra > scripts and programs written in the Maple scripting language that would > demonstrate the many cool features that you could do with the GUI program. > (Let me tell you.. there were some pretty cool things in those scripts.) > During the Maple installation process, the user was asked/prompted to > install the Shared CD if they wanted. Totally optional. > > However, the "Shared" CD contents, while provided with the box that you > paid for, was not officially supported by Maple. Each script was copyright > by the script author and the user was encouraged to contact the script > author directly if they had any questions, comments, or bug fixes to > report. I believe that we also had the 'Shared' scripts on an FTP site > somewhere so the authors could update their scripts for a subsequent release > and users could check to see if there was an update to their particular > script of interest. > > As a Maple user, if you wanted to include any of the shared scripts you > simply had to navigate to the correct folder and pick the one you wanted. > We, the formal QA/test team, were off the hook for testing these scripts > (thank God!), but let me tell you that many of them were really handy when > it came time to regression testing! > > So my two cents on this thread is that I also think it is a good idea to > include the half-baked code with Watir. I'm in favour of calling the folder > 'contrib' or 'shared' rather than 'experimental'. The scripts should have a > standard header format that identifies the author/contributor, script > version number (or date), and a simple disclaimer of some sort that directs > the user to the author or the Wtr-general mailing list if they have any > questions/comments/bugs to share. Heck, we could probably even set up a new > wiki or mailing list specifically for discussing the half-baked/shared > script contributions if there's interest in keeping that separate. (I don't > know that we need to, but I'm just throwing the idea out there.) > > Hope this helps. Cheers. > Paul Carvalho > > > > On 11/09/06, Sy Ali wrote: > > > > On 9/10/06, Charley Baker wrote: > > > A contrib directory along with a script to include or instructions on > > the > > > load path in order to load the contributions makes most sense to me, > > I'm > > > still a bit hazy about how best this would work among general users. I > > don't > > > like the idea of a testing "branch", but rather an easy way to > > incorporate > > > user contribs via a contrib directory, two choices: > > > > > > we package all the contribs up into a loaded directory > > > user chooses files to download into a loaded directoryI'd opt for the > > second > > > choice, whoever is using user contribs needs to know that these are > > separate > > > and not supported by the larger community. Ideally they should be > > supported > > > by the people who wrote them on the wiki. Before any user contrib is > > added > > > to the main branch, it must have unit tests. A new category should be > > added > > > to jira for contributions. > > > > Being able to dynamically load/include user scripts from a user script > > repository is a really cool idea. As long as there's a simple way to > > add/remove or enable/disable user scripts -- since watir has many > > young programmers -- it would probably go over quite well. > > > > Have any other projects done something similar to this? > > > > > _______________________________________________ > Wtr-core mailing list > Wtr-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-core > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060911/764b6d52/attachment.html From charley.baker at gmail.com Mon Sep 11 13:13:58 2006 From: charley.baker at gmail.com (Charley Baker) Date: Mon, 11 Sep 2006 11:13:58 -0600 Subject: [Wtr-core] Half-baked code In-Reply-To: References: <1e55af990609100540s628a8e98g306d9cecb780f4c2@mail.gmail.com> <1e55af990609110301u54417ed6p2ef786da846bfe4c@mail.gmail.com> <37c405480609110734h2bb877c6sb7e5ee51d41a02a@mail.gmail.com> Message-ID: I also like the idea of the template header file that you mentioned. The more consistency that we can have with any additions the more likely they'll be used. Likewise, it's important to have unit tests for any user contributed code, without unit tests it might be useful, but not adopted into the trunk until tests are added. -Charley On 9/11/06, Bret Pettichord wrote: > > This is a good example of what i'm hoping to achieve. Perhaps you can > share this story with wtr-general when we announce the plan there. > > On 9/11/06, Paul Carvalho wrote: > > > Hi there. I can't speak to other Ruby projects, but I can share an > experience from a company I worked at nearly a decade ago. I worked at > Waterloo Maple Inc ( http://www.maplesoft.com/ ) a while back and tested > the main Maple package. I offer the story here as an anecdote because I > think it's relevant. > > If you're not familiar with it, Maple is a math/calculus programming > environment where you can feed it equations and it will solve them for you. > (Useful to University students and Engineering firms mostly.) It had two > basic interfaces: Command Line and GUI. The Command Line module was a > direct interface to the math engine and we had a team of PhD's who were > responsible for the testing scripts that ensured the math worked as > expected. The GUI test team, of which I was a part, was responsible for > testing everything else. There was a lot in the GUI to cover so we also had > an ongoing Beta program to manage real-usage feedback from professors and > engineers all over the world. > > Here's the relevant part. In addition to the main program CD, there was a > bonus "Shared" CD that was included. On this CD was a few hundred extra > scripts and programs written in the Maple scripting language that would > demonstrate the many cool features that you could do with the GUI program. > (Let me tell you.. there were some pretty cool things in those scripts.) > During the Maple installation process, the user was asked/prompted to > install the Shared CD if they wanted. Totally optional. > > However, the "Shared" CD contents, while provided with the box that you > paid for, was not officially supported by Maple. Each script was copyright > by the script author and the user was encouraged to contact the script > author directly if they had any questions, comments, or bug fixes to > report. I believe that we also had the 'Shared' scripts on an FTP site > somewhere so the authors could update their scripts for a subsequent release > and users could check to see if there was an update to their particular > script of interest. > > As a Maple user, if you wanted to include any of the shared scripts you > simply had to navigate to the correct folder and pick the one you wanted. > We, the formal QA/test team, were off the hook for testing these scripts > (thank God!), but let me tell you that many of them were really handy when > it came time to regression testing! > > So my two cents on this thread is that I also think it is a good idea to > include the half-baked code with Watir. I'm in favour of calling the folder > 'contrib' or 'shared' rather than 'experimental'. The scripts should have a > standard header format that identifies the author/contributor, script > version number (or date), and a simple disclaimer of some sort that directs > the user to the author or the Wtr-general mailing list if they have any > questions/comments/bugs to share. Heck, we could probably even set up a new > wiki or mailing list specifically for discussing the half-baked/shared > script contributions if there's interest in keeping that separate. (I don't > know that we need to, but I'm just throwing the idea out there.) > > Hope this helps. Cheers. > Paul Carvalho > > > > On 11/09/06, Sy Ali wrote: > > > > On 9/10/06, Charley Baker < charley.baker at gmail.com > wrote: > > > A contrib directory along with a script to include or instructions on > > the > > > load path in order to load the contributions makes most sense to me, > > I'm > > > still a bit hazy about how best this would work among general users. I > > don't > > > like the idea of a testing "branch", but rather an easy way to > > incorporate > > > user contribs via a contrib directory, two choices: > > > > > > we package all the contribs up into a loaded directory > > > user chooses files to download into a loaded directoryI'd opt for the > > second > > > choice, whoever is using user contribs needs to know that these are > > separate > > > and not supported by the larger community. Ideally they should be > > supported > > > by the people who wrote them on the wiki. Before any user contrib is > > added > > > to the main branch, it must have unit tests. A new category should be > > added > > > to jira for contributions. > > > > Being able to dynamically load/include user scripts from a user script > > repository is a really cool idea. As long as there's a simple way to > > add/remove or enable/disable user scripts -- since watir has many > > young programmers -- it would probably go over quite well. > > > > Have any other projects done something similar to this? > > > > > _______________________________________________ > Wtr-core mailing list > Wtr-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-core > > > > _______________________________________________ > Wtr-core mailing list > Wtr-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-core > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060911/bfcbac19/attachment-0001.html From bret at pettichord.com Mon Sep 11 14:36:40 2006 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 11 Sep 2006 13:36:40 -0500 Subject: [Wtr-core] Half-baked code In-Reply-To: References: <1e55af990609100540s628a8e98g306d9cecb780f4c2@mail.gmail.com> <1e55af990609110301u54417ed6p2ef786da846bfe4c@mail.gmail.com> <37c405480609110734h2bb877c6sb7e5ee51d41a02a@mail.gmail.com> Message-ID: On 9/11/06, Charley Baker wrote: > > I also like the idea of the template header file that you mentioned. The > more consistency that we can have with any additions the more likely they'll > be used. Likewise, it's important to have unit tests for any user > contributed code, without unit tests it might be useful, but not adopted > into the trunk until tests are added. > Actually, what i want to do is create a place for user-contributed code that does not have unit tests. One of the problems we have right now, is that we have user-contributed code in the core Watir distribution that does not have unit tests -- or which has unit tests that fail, which isn't much better. Have you run all-tests.rb recently? So i both need a place to move existing Watir code that is unfinished so that i can make clear to users that we know this code is unfinished. And i need to have a place to put many user contributions that are useful but do not have unittests. A good example is watir_simple.rb -- we don't have unit tests for this, and some users get confused about how to use this, but i think we all agree that Watir is better with this than without -- i just want to make it clear that this is an example of something you can do with watir -- or something you can use -- if you take responsibility for supporting/extending it yourself. I've been holding the kind of hard-line that you suggest and it isn't working. Nothing is being contributed and i'm spending most of my time pissing off potential contributors instead of working on code. My hope is that people will see contrib code that they want to be supported and this might motivate them to write the tests for it. Maybe. Bret -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060911/f35d06ac/attachment.html From sy1234 at gmail.com Mon Sep 11 19:26:46 2006 From: sy1234 at gmail.com (Sy Ali) Date: Mon, 11 Sep 2006 18:26:46 -0500 Subject: [Wtr-core] Half-baked code In-Reply-To: References: <1e55af990609100540s628a8e98g306d9cecb780f4c2@mail.gmail.com> <1e55af990609110301u54417ed6p2ef786da846bfe4c@mail.gmail.com> <37c405480609110734h2bb877c6sb7e5ee51d41a02a@mail.gmail.com> Message-ID: <1e55af990609111626q4fa6bdf6x90f79e8f2be44b23@mail.gmail.com> On 9/11/06, Bret Pettichord wrote: > My hope is that people will see contrib code that they want to be supported > and this might motivate them to write the tests for it. Maybe. Or it might help semi-commited contributors become more serious, because they know their code has to rise to a certain level to ever be considered for insertion into the main trunk. From bret at pettichord.com Mon Sep 11 20:15:29 2006 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 11 Sep 2006 19:15:29 -0500 Subject: [Wtr-core] Half-baked code In-Reply-To: <1e55af990609111626q4fa6bdf6x90f79e8f2be44b23@mail.gmail.com> References: <1e55af990609100540s628a8e98g306d9cecb780f4c2@mail.gmail.com> <1e55af990609110301u54417ed6p2ef786da846bfe4c@mail.gmail.com> <37c405480609110734h2bb877c6sb7e5ee51d41a02a@mail.gmail.com> <1e55af990609111626q4fa6bdf6x90f79e8f2be44b23@mail.gmail.com> Message-ID: On 9/11/06, Sy Ali wrote: > > On 9/11/06, Bret Pettichord wrote: > > My hope is that people will see contrib code that they want to be > supported > > and this might motivate them to write the tests for it. Maybe. > > Or it might help semi-commited contributors become more serious, > because they know their code has to rise to a certain level to ever be > considered for insertion into the main trunk. Exactly. And if not them, maybe someone else who is using the code. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-core/attachments/20060911/290e4afb/attachment.html From bret at pettichord.com Mon Sep 18 16:46:38 2006 From: bret at pettichord.com (Bret Pettichord) Date: Mon, 18 Sep 2006 15:46:38 -0500 Subject: [Wtr-core] awta 7 will be jan 12-14 Message-ID: The next Austin Workshop on Test Automation will be Jan 12-14. Co-hosts will be Chris McMahon, Mike Kelly (both on this list) and Carl Erickson. We are looking for presentations from people with experience using open-source software. We'll have a full public announcement out soon. Bret