[yast-devel] RFC: New rules for yast-maintainers
Hi, As Gabi has pointed-out today, we have a growing list of bugs reported for Yast, assigned to the default assignee: yast-maintainers. Some of the bugs cannot be fixed easily now as we do not have a single person who would take care about "that particular module", "usability" or "design". For me, this is a perfect way for fixing bugs in an agile way: - Project manager decides what needs to be fixed and when - We will find out who can fix or which expertise we need - And we'll either assign these bugs to respective people in time or try to find help outside But we need to find a way how not to get lost in bugs assigned to yast-maintainers. And there are several possibilities: 1. NEW bug needs to be checked and either reassigned or at least marked as reviewed/confirmed 2. CONFIRMED bug should have a [yast2-*] in Summary, so we know it has been reviewed already / or we could add new keyword e.g. "reviewed". The current "Yast Maintainer" must make sure that summary describes the issue well 3. IN_PROGRESS should have a real assignee, this would need cooperation with PjM/PM, so they set real priority 4. We will definitely not be able to fix all bugs, so there needs to be a way to drop as CANTFIX/WONTFIX according to given criteria 5. Features should be closed as FEATURE and the reported advised to use FATE. 6. Yast maintainer should take care only about bugs that haven't been reviewed, for that a simple search should be possible (e.g.: doesn't contain `reviewed` flag) Please review, and/or come with better ideas. I know this is yet another rule-set, maybe you'll have a better idea. Bye Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader Cloud & Systems Management Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Wed, 29 Oct 2014 17:07:16 +0100
Lukas Ocilka
Hi,
As Gabi has pointed-out today, we have a growing list of bugs reported for Yast, assigned to the default assignee: yast-maintainers. Some of the bugs cannot be fixed easily now as we do not have a single person who would take care about "that particular module", "usability" or "design".
For me, this is a perfect way for fixing bugs in an agile way: - Project manager decides what needs to be fixed and when - We will find out who can fix or which expertise we need - And we'll either assign these bugs to respective people in time or try to find help outside
But we need to find a way how not to get lost in bugs assigned to yast-maintainers. And there are several possibilities:
1. NEW bug needs to be checked and either reassigned or at least marked as reviewed/confirmed 2. CONFIRMED bug should have a [yast2-*] in Summary, so we know it has been reviewed already / or we could add new keyword e.g. "reviewed". The current "Yast Maintainer" must make sure that summary describes the issue well 3. IN_PROGRESS should have a real assignee, this would need cooperation with PjM/PM, so they set real priority 4. We will definitely not be able to fix all bugs, so there needs to be a way to drop as CANTFIX/WONTFIX according to given criteria 5. Features should be closed as FEATURE and the reported advised to use FATE. 6. Yast maintainer should take care only about bugs that haven't been reviewed, for that a simple search should be possible (e.g.: doesn't contain `reviewed` flag)
Please review, and/or come with better ideas. I know this is yet another rule-set, maybe you'll have a better idea.
Bye Lukas
Hi, I thinki your suggestion make sense. I just worry if it do not take too much time for trivial bugs with raised exception that can be usually fixed in few minutes. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 29.10.2014 um 17:07 schrieb Lukas Ocilka:
Hi,
As Gabi has pointed-out today, we have a growing list of bugs reported for Yast, assigned to the default assignee: yast-maintainers. Some of the bugs cannot be fixed easily now as we do not have a single person who would take care about "that particular module", "usability" or "design".
For me, this is a perfect way for fixing bugs in an agile way: - Project manager decides what needs to be fixed and when - We will find out who can fix or which expertise we need - And we'll either assign these bugs to respective people in time or try to find help outside
But we need to find a way how not to get lost in bugs assigned to yast-maintainers. And there are several possibilities:
1. NEW bug needs to be checked and either reassigned or at least marked as reviewed/confirmed 2. CONFIRMED bug should have a [yast2-*] in Summary, so we know it has been reviewed already / or we could add new keyword e.g. "reviewed". The current "Yast Maintainer" must make sure that summary describes the issue well CONFIRMED state even with [yast2-*] might not be a clear criteria that bug is reviewed (could be reassigned to yast2-maintainers, some reporter also add module names...). I think we should use a keyword (or flag) to clearly mark that bug is seen and reviewed by current YaST maintainer. 3. IN_PROGRESS should have a real assignee, this would need cooperation with PjM/PM, so they set real priority 4. We will definitely not be able to fix all bugs, so there needs to be a way to drop as CANTFIX/WONTFIX according to given criteria 5. Features should be closed as FEATURE and the reported advised to use FATE. 6. Yast maintainer should take care only about bugs that haven't been reviewed, for that a simple search should be possible (e.g.: doesn't contain `reviewed` flag) Agreed, we should have the possibility to search for not reviewed bugs (using a flag or keyword).
Gabi
Please review, and/or come with better ideas. I know this is yet another rule-set, maybe you'll have a better idea.
Bye Lukas
- -- Gabriele Mohr SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstr. 5 Tel: +49 911 740 53 362 90409 Nürnberg Email: gs@suse.de - ----------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFUUgESzwhO63ql6h0RAmGuAJwLZg+5WeNe2osV2graPqsVuyLouQCeNIDz xeGhdz0U96y0ITmKC2m+FUo= =4voe -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Wed, Oct 29, 2014 at 05:07:16PM +0100, Lukas Ocilka wrote:
Hi,
As Gabi has pointed-out today, we have a growing list of bugs reported for Yast, assigned to the default assignee: yast-maintainers. Some of the bugs cannot be fixed easily now as we do not have a single person who would take care about "that particular module", "usability" or "design".
For me, this is a perfect way for fixing bugs in an agile way: - Project manager decides what needs to be fixed and when - We will find out who can fix or which expertise we need - And we'll either assign these bugs to respective people in time or try to find help outside
But we need to find a way how not to get lost in bugs assigned to yast-maintainers. And there are several possibilities:
1. NEW bug needs to be checked and either reassigned or at least marked as reviewed/confirmed 2. CONFIRMED bug should have a [yast2-*] in Summary, so we know it has been reviewed already / or we could add new keyword e.g. "reviewed". The current "Yast Maintainer" must make sure that summary describes the issue well 3. IN_PROGRESS should have a real assignee, this would need cooperation with PjM/PM, so they set real priority 4. We will definitely not be able to fix all bugs, so there needs to be a way to drop as CANTFIX/WONTFIX according to given criteria 5. Features should be closed as FEATURE and the reported advised to use FATE. 6. Yast maintainer should take care only about bugs that haven't been reviewed, for that a simple search should be possible (e.g.: doesn't contain `reviewed` flag)
Please review, and/or come with better ideas. I know this is yet another rule-set, maybe you'll have a better idea.
Once thing I currently dislike is the misuse of the title for
various flags. Maybe the "Whiteboard" can be used for that. It
would also make it less likely other people mess with our flags.
ciao
Arvin
--
Arvin Schnell,
participants (4)
-
Arvin Schnell -
Gabriele Mohr -
Josef Reidinger -
Lukas Ocilka