HI, I haven't been paying attention to your fork, but since I am working on a some rdoc fix fork I want to clarify some things on my style of thinking
I like to think of changes as two classes of issues: 1. impediments to overcome, pain to address (improve feature, fix bugs) 2. setting up for next moves (infrastructure to support workflow, future forks, features etc..) So I am also working on a fork to fix documentation and packaging of gems. for example the impediments I want to address: - update the rdoc and make it nice for watir, firewatir and commonwatir. - make it work with yard (for rdoc.info and yardoc) - remove unittests from gem package (not needed to be in gem since they won't run, users complain) And for next moves are: - move to jeweler for gemspec creation and packaging and version management (we've already moved away from hoe) - make some kind of demo, examples gem to run with watir, firewatir etc.. and use a site so people can gem install watir and gem install watirdemogemthing and just run it on their machines. there are more.. So I am not sure what your changing of class names addresses and what's the reason for breaking existing functionality? can you list the issues? Do you have tests for them that show the reason why something is a certain way? This would help me and others I think to look at considering changes. marekj Watirloo: Semantic Page Objects in UseCases http://github.com/marekj/watirloo/ Support Watir Project http://pledgie.com/campaigns/2982 On Wed, Jan 20, 2010 at 3:29 PM, Ethan <[email protected]> wrote: > Dear Watir Development, > > I am wondering how people around here feel about my fork. It has been some > time, and I think it is much closer to being ready to be used by most users. > It has been in use by the SQA team at my company for quite a while now, > though we don't use all of the functionality that the current Watir gem > provides, some of which has been broken by my fork and I have been slow to > fix. > At this point though, I think it's about ready - with a couple significant > exceptions of implementing changes discussed here relating to class names > (changing Watir::IETextField to Watir::IE::TextField), and implementing > something that works for interacting with modal dialogs/popups. > > So, with things approaching what I feel will soon be a ready state for users > to be using my work, I'd like feedback on the fork. Do people here feel that > my changes are something that could be merged into the main Watir codebase? > If so, what would need to be done with it for that to happen? If not, why > not? (is anybody even paying any attention to it?) > > I hope to hear from those involved with watir, so I can figure out what > direction to take my work as it forms into something really usable. > > Thanks, > -Ethan > > > _______________________________________________ > Wtr-development mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/wtr-development > _______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
