wxruby users - May 2005 - Making it easier to contribute wxRuby-SWIG code

After seeing contributions from Dmitry and Alex, I''m wondering how we 
can better organize and encourage user contributions.

ORGANIZING
Maybe identifying what is still missing in wxRuby-SWIG and publishing a 
prioritized todo list could useful to contributors.

GETTING NOTICED
It might be useful to post a link to the unassigned todo list each month 
to comp.lang.ruby and ask for voluteers.  I''m sure there are folks that
wouldn''t mind using wxRuby as a way to learn/practice ruby and SWIG.

GIVING RECOGNITION
At each volunteer''s option, it would be a nice gesture to give them 
credit for their contribution on the wxRuby website.  For some, this 
might serve as additional incentive to contribute.

DJB wrote:
> ORGANIZING
> Maybe identifying what is still missing in wxRuby-SWIG and publishing 
> a prioritized todo list could useful to contributors.
I''ve run out a quick list comparing wxruby-swig (plus a few eg 
GridCellEditor) compared to wxruby 0.6.0 . It''s on the wiki at the 
bottom of the page at

http://wxruby.rubyforge.org/wiki/wiki.pl?How_To_Add_A_New_Class_To_Wxruby-Swig

The more wxruby-swig matches the classes available in wxruby, the wider 
the audience of people with existing Wx applications who can try running 
their existing ruby code against the wxruby-swig.

a

Alex Fenton wrote:
> I''ve run out a quick list comparing wxruby-swig (plus a few eg
> GridCellEditor) compared to wxruby 0.6.0 . It''s on the wiki at the
> bottom of the page at
> 
>
http://wxruby.rubyforge.org/wiki/wiki.pl?How_To_Add_A_New_Class_To_Wxruby-Swig
Excellent. I just added a note mentioning that not all of the
"missing"
classes actually should be implemented in wxruby-swig. Several of them
appear (at a glance) to duplicate functionality already present in Ruby.
Whenever possible, people writing wxruby apps should use standard Ruby
features rather than wx equivalents.

Kevin