On Wed, Aug 23, 2023 at 9:54 AM Neal Gompa <ngompa13 at gmail.com> wrote: > > 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 My personal tolerance for inconvenience has no bearing on the ability to enact a change. > 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. Noted. I'm not sure what else you'd like me to do at this point, so we should probably stop furthering this subthread. josh