Difference between revisions of "BugParty"

From Inkscape Wiki
Jump to: navigation, search
(edit for the announcement text)
(Categorization)
(2 intermediate revisions by 2 users not shown)
Line 5: Line 5:
 
Bug Party Invitation
 
Bug Party Invitation
  
In an effort to organize the bug tracker and the feature tracker, the Inkscape project will organize a "Bug Party" on Saturday, September 24, 2005. This is an opportunity for new contributors and non-developers to help the project in triaging, closing, prioritizing and clarifying bugs and feature requests.
+
In an effort to beat the bug tracker and the feature tracker into submission, the Inkscape project is hosting a "Bug Party" on Saturday, September 24, 2005. This is an excellent opportunity for new contributors and non-developers to participate in the project.
  
 
All day long (in the US time) the IRC channel #inkscape on server irc.freenode.org will be open, along with the correspondent Jabber room (see http://inkscape.org/discussion.php for more details). We expect to reach peak hours at 16-20 UTC on September 24 (8-12 PST) and 0-4 UTC on September 25 (16-20 PST on September 24) and guarantee presence of core Inkscape developers on those time intervals.
 
All day long (in the US time) the IRC channel #inkscape on server irc.freenode.org will be open, along with the correspondent Jabber room (see http://inkscape.org/discussion.php for more details). We expect to reach peak hours at 16-20 UTC on September 24 (8-12 PST) and 0-4 UTC on September 25 (16-20 PST on September 24) and guarantee presence of core Inkscape developers on those time intervals.
Line 27: Line 27:
  
 
== Objectives: ==
 
== Objectives: ==
* trim down the number of open bugs/enhancement request. we should find old bugs which are not existing anymore, features already implemented and not closed in the tracker, duplicates and, why not, quick fixes.
+
* trim down the number of open bugs/enhancement request. we should find old bugs which do not exist anymore, features already implemented and not closed in the tracker, duplicates and, why not, quick fixes.
  
 
== Rules: ==
 
== Rules: ==
* if a bug report is one release old/one month old, we can't reproduce it and don't have any follow-up from the poster, it can be closed;
+
* if a bug report is one release old/one month old, we can't reproduce it and don't have any follow-up from the poster, then it can be closed;
 +
* code to fix bugs is to be posted as patches to the patch tracker for review and integration
  
 
== Procedures: ==
 
== Procedures: ==
* is possible to post to the tracker without login to sourceforge.net, but a login is recommended, because this improve your ability to follow-up a post;
+
* is possible to post to the tracker without login to sourceforge.net, but a login is recommended, because this improve your ability to follow-up later;
 
* not everyone is allowed to close a bug, so people without this right should comment in the bug reasoning why the bug should be closed (is a duplicate, not happen anymore, can't be reproduced). We should define a way to work after that, alternatives are:
 
* not everyone is allowed to close a bug, so people without this right should comment in the bug reasoning why the bug should be closed (is a duplicate, not happen anymore, can't be reproduced). We should define a way to work after that, alternatives are:
 
** put in a message a special string, like TOCLOSE, which can be queried later, for closure;
 
** put in a message a special string, like TOCLOSE, which can be queried later, for closure;
 
** announce the bug number on the chat channel, so it can be closed interactively;
 
** announce the bug number on the chat channel, so it can be closed interactively;
 
** put the URL of the bug in the wiki page.
 
** put the URL of the bug in the wiki page.
* if a feature request would never be implemented, it can be closed, but with good reasoning of why it will not be implemented (like not whithin the scope of a vector drawing application, not compatible with the existing codebase)
+
* if a feature request would never be implemented, it can be closed, but with good reasoning of why it will not be implemented (like not within the scope of a vector drawing application, not compatible with the existing codebase)
  
 
== Tools: ==
 
== Tools: ==
Line 52: Line 53:
 
* the Inkscape developer mailing list: inkscape-devel AT lists.sourceforge.net
 
* the Inkscape developer mailing list: inkscape-devel AT lists.sourceforge.net
 
* How to report a bug: http://inkscape.org/report_bugs.php
 
* How to report a bug: http://inkscape.org/report_bugs.php
 +
 +
[[Category:Wiki Attic]]

Revision as of 00:43, 27 June 2006

Bug Party

Announcement:

Bug Party Invitation

In an effort to beat the bug tracker and the feature tracker into submission, the Inkscape project is hosting a "Bug Party" on Saturday, September 24, 2005. This is an excellent opportunity for new contributors and non-developers to participate in the project.

All day long (in the US time) the IRC channel #inkscape on server irc.freenode.org will be open, along with the correspondent Jabber room (see http://inkscape.org/discussion.php for more details). We expect to reach peak hours at 16-20 UTC on September 24 (8-12 PST) and 0-4 UTC on September 25 (16-20 PST on September 24) and guarantee presence of core Inkscape developers on those time intervals.

For additional information, rules, procedures and tools, a Wiki page is available: http://wiki.inkscape.org/cgi-bin/wiki.pl?BugParty

If you are an Inkscape user looking for a way to contribute or an existing contributor wanting to contribute more, we await you!


To be distributed at:

  • Inkscape users list;
  • Inkscape test list;
  • Openclipart list;
  • Scribus list?;
  • news item on front page (aggregated to various Planet sites).

Fun Stuff:

Objectives:

  • trim down the number of open bugs/enhancement request. we should find old bugs which do not exist anymore, features already implemented and not closed in the tracker, duplicates and, why not, quick fixes.

Rules:

  • if a bug report is one release old/one month old, we can't reproduce it and don't have any follow-up from the poster, then it can be closed;
  • code to fix bugs is to be posted as patches to the patch tracker for review and integration

Procedures:

  • is possible to post to the tracker without login to sourceforge.net, but a login is recommended, because this improve your ability to follow-up later;
  • not everyone is allowed to close a bug, so people without this right should comment in the bug reasoning why the bug should be closed (is a duplicate, not happen anymore, can't be reproduced). We should define a way to work after that, alternatives are:
    • put in a message a special string, like TOCLOSE, which can be queried later, for closure;
    • announce the bug number on the chat channel, so it can be closed interactively;
    • put the URL of the bug in the wiki page.
  • if a feature request would never be implemented, it can be closed, but with good reasoning of why it will not be implemented (like not within the scope of a vector drawing application, not compatible with the existing codebase)

Tools: