On Wed, Aug 23, 2023 at 9:42 AM Josh Boyer <jwboyer at redhat.com> wrote: > > On Wed, Aug 23, 2023 at 9:39 AM Neal Gompa <ngompa13 at gmail.com> wrote: > > > > On Wed, Aug 23, 2023 at 9:28 AM Josh Boyer <jwboyer at redhat.com> wrote: > > > > > > On Wed, Aug 23, 2023 at 8:46 AM Neal Gompa <ngompa13 at gmail.com> wrote: > > > > > > > > On Wed, Aug 23, 2023 at 6:51 AM Florian Weimer <fweimer at redhat.com> wrote: > > > > > > > > > > The Red Hat Platform Tools team (who maintain binutils, GCC, gdb, glibc, > > > > > systemtap, valgrind, etc.) have begun to move bugs from > > > > > bugzilla.redhat.com to issues.redhat.com, to the project called “RHEL”. > > > > > > > > > > We'd appreciate if future issues discovered in CentOS Stream were filed > > > > > there directly. When filing new issues, please make sure that the > > > > > Security Level is set to None, so that others can contribute, and select > > > > > “CentOS Stream” under Projects. Please do not use the public “CS” > > > > > project for reporting issues in specific RPM packages because we > > > > > (Platform Tools) do not monitor it. (Compose issues and CentOS Stream > > > > > issues should still be reported in “CS”.) > > > > > > > > > > > > > The Red Hat Jira CS project currently blocks community members from > > > > filing issues or making comments. > > > > > > > > > Community members should be able to create a Red Hat account on > > > > > sso.redhat.com and use that to login to issues.redhat.com. As far as I > > > > > know, it's not necessary to agree to the Red Hat Enterprise Agreement, > > > > > or any subscription terms. If that has changed, please let me know. > > > > > > > > > > > > > I don't know this personally, since my account is old and originates > > > > from the JBoss JIRA instance, but I've been told that you are required > > > > now to disclose address and phone number and agree to the RHEA TOS to > > > > access the Jira when you create your account. It would be worth > > > > double-checking this. > > > > > > > > > The user experience should remain largely unchanged, although the > > > > > underlying technology is completely different (Jira vs Bugzilla). If a > > > > > bug is migrated, a notification is posted to the Bugzilla bug, with > > > > > instructions how to find the migrated issue on issues.redhat.com. You > > > > > will likely have to re-subscribe to the new issue after migration. In > > > > > the future, logging into issues.redhat.com from time to time (every few > > > > > weeks or months) will be required to keep receiving notification for > > > > > your bug subscriptions. > > > > > > > > > > > > > Please fix this and don't make accounts go automatically inactive. > > > > That's annoying and painful. > > > > > > To my understanding, this will not be changed. Inactive accounts are > > > culled to reduce seat license counts. I believe the cutoff is > > > 90-days. While I agree it's a change in behavior and somewhat > > > annoying, logging into the instance once a quarter does not seem > > > onerous for someone that wants to actively participate. > > > > > > > It is onerous for people who use CentOS Stream and file bug reports > > waiting for responses given the current lag times. BZes already don't > > get responses for weeks or months in some cases. Even as an active > > participant (if you'd like to count me as one), most of *my* BZes get > > nothing for months. I have no reason to regularly check Jira for my > > issues because there's nothing going on anyway. > > > > It's not "somewhat annoying", it's actually really bad. If you really > > need to worry about seat counts, then adjust the inactivity period to > > align with how long it takes for someone to respond to a ticket. > > Probably one to two years is more appropriate. > > > > I do not think it is reasonable to disable volunteer user/contributor > > accounts like this, especially since it disables your watch lists in > > Jira. > > OK. I will state this more clearly. > > You asked to change this. I inquired if it could be changed > internally. The answer is no, it cannot. > > I'm not trying to justify or argue the merits of the existing > mechanism. I am trying to set clear expectations so people are aware > of the way it works and can plan accordingly. > I am not refuting your base premise that you cannot deactivate accounts after a period of time. I am, however, telling you *why* this is onerous as you seem to believe it is not. If you intend to use metrics for determining participation, then you're going to have problems because of the issues I stated. I even offered a suggestion of a more reasonable timeline for deactivation based on the current lag times. Unless something changes on your side, this is going to be a downgrade overall from an engagement and usability perspective for contributors. -- 真実はいつも一つ！/ Always, there's only one truth!