I would like to announce a Zope 2 Bug Day for Monday Dec. 16, starting at 8:00am US Eastern Standard Time. We will be fixing bugs in preparation for the Zope 2.6.1 release. What is a Bug Day? A Bug Day is a day dedicated to "squashing" bugs lodged in the Zope2 collector at http://collector.zope.org/Zope. Anyone may participate. It is best if you can set aside an entire day for bug-squashing, but any amount of time you can spare is obviously useful. Developers and any other interested parties should gather via IRC on the #zope-dev channel on irc.openprojects.net at the time and date above. Thanks! - C
On Thursday 05 December 2002 5:14 pm, Chris McDonough wrote:
Developers and any other interested parties should gather via IRC on the #zope-dev channel on irc.openprojects.net at the time and date above.
I think its worth saying that the most important (IMO) outcome from the last two bugs days has been *concensus* about which bugs can be forgotten about, or rejected, and which are most important. You dont need to be a hardened zope developer to make a valuable contribution.
On Thu, 5 Dec 2002 21:33:19 +0000 Toby Dickenson <tdickenson@geminidataloggers.com> wrote:
Developers and any other interested parties should gather via IRC on the #zope-dev channel on irc.openprojects.net at the time and date above.
I think its worth saying that the most important (IMO) outcome from the last two bugs days has been *concensus* about which bugs can be forgotten about, or rejected, and which are most important. You dont need to be a hardened zope developer to make a valuable contribution.
What a coincidence. A few days ago I wrote some text regarding 623 issue (but not posted) which also mentions consensus issue: Consensus problem ----------------- Unicode support is particularly hard to have the consensus, as the benefit/impact of the specification is significantly different among people of different regions in the world. As Zope's popularity is becoming worldwide, difference of the impacts of cultural-sensitive specification is becoming larger. For instance, while one region may get benefit from one change in specification without problem, other region may suffer from it. Also, it's harder to realize/measure the impacts on different regions, as it requires deep knowledge of different cultures. The difficulty of I18N lies rather in that aspect, not in technical difficulties. Regards, --- Heiichiro NAKAMURA <nheiich@quantumfusion.com>
participants (3)
-
Chris McDonough -
Heiichiro NAKAMURA -
Toby Dickenson