| larowlan |
Issue triage creditsDrupalcon Europe submissionCore 8.9 and 9.1 are now security only |
| mohit_aghera |
+1 to DrupalCon Europe Submission |
| quietone |
An item to approve the previous minutes. |
| quietone |
New initiative page needs formatting, https://www.drupal.org/node/3215948 |
| Spokje |
How to handle the "endless" stream of people posting a screenshot that a patch applied OK and/or giving an RTBC+1 without putting the issue on RTBC. Could be gaming the system, could be pure enthusiasm, could be the documentation being not clear.Is there something we can do to help? (edited) |
| Spokje |
RTBC patches, is there something we can do to prevent them from rerolling them for ages until a core committer commits/reacts? |
| dww |
@larowlan not sure if you saw @Spokje’s suggested threads... |
| larowlan |
sorry, was in a call |
| Kristen Pol (she/her) |
Late to the party but any mentored contribution events coming up? |
| ambermatz |
I would appreciate some general guidance/education on discerning between support requests and bugs. I tend to want to help, but I also want to be a more effective “triager”, so any tips are appreciated. |
| larowlan |
It would be great for our little team to feature again at Drupalcon |
| larowlan |
@lendude presented last year, and I presented at DC NA |
| larowlan |
It would be good for someone who has not presented before and is looking for an opportunity to speak to do so |
| larowlan |
e.g. @mohit_aghera if you're keen to submit on our behalf, +1 |
| larowlan |
I suspect we'd just re-fresh the slides with new stats and add some personalised touches |
| larowlan |
Also, if there's ideas for more focussed sessions (like one on testing as you mentioned), that'd be great |
| mohit_aghera |
I’m open for it. |
| mohit_aghera |
Yes, I’m thinking since quite some time about the test cases. I’ll draft something. |
| mohit_aghera |
@lendude, are you willing to pair up for that test cases related session, may be we can take it forward. |
| lendude |
@mohit_aghera not sure I’ll be at Drupalcon yet, I’m thinking about just submitting the Kickstart testing talk, but haven’t made up my mind yet :shrug: |
| mohit_aghera |
@larowlan, I’ll share the draft for “Bug-smash initiative updates” session today, so you can have a look at it and I’ll submit it after that. |
| larowlan |
sounds good, thanks |
| Kristen Pol (she/her) |
@mohit_aghera thanks for submitting something:) |
| larowlan |
This means when you're triaging, anything that is open for backport for 9.1 and 8.9 can be marked fixed and have the version updated to the lowest version it was committed to. |
| larowlan |
Only issues that help people upgrade would be eligible for backport (and security issues obviously) |
| kimb0 |
I saw an issue you commented on yesterday that was against 9.1.x |
| kimb0 |
#3213572: #date_time_callbacks and #date_date_callbacks bypass the TrustedCallbackInterface protections |
| kimb0 |
shouldn't that be against 9.3.x? |
| larowlan |
I'll move it to 9.2.x (lowest version it could go into) |
| quietone |
And what happens to the existing 8.9 and 9.1 bug reports? |
| larowlan |
if they still exist in 9.2, they get moved there |
| dww |
9.2.0 final isn't even out yet. The vast majority of D9 sites have got to still be on 9.1.x branch. Why aren't we still back-porting bug fixes there? |
| Spokje |
Insert wild stab in the dark: Isn't the backporting still happening by committers discretion? |
| larowlan |
9.1 has had its final bugfix release |
| larowlan |
so backporting isn't going to make it into a release |
| dww |
require_once('the_drop_is_always_moving.inc'); :nerd_face: (edited) |
| Spokje |
define("PREFERRED_DIRECTION", "forward"); |
| larowlan |
I think gently pointing people to the right way of doing things is the best/only option here |
| Spokje |
I think I have to agree there.There is however one thing that makes it "profitable" to upload a screenshot:AFAIK the uploader of any file (be it patch, screenshot, the latest local weather forecast or whatever) is automagically added to the credit list of that issue.Would it be an option to not auto-credit when uploading just an image?Not sure who handles those rules and if this is an option, but IMHO it would make it less attractive/profitable for any potential "Playing-the-System". |
| dww |
One of the principles of a bodywork modality that I instruct is to try to always be simultaneously "firm and gentle". I think "gently" pointing people to the right way is great. And for committers to be firm about un-crediting people who do it wrong so that folks aren't getting credit for such "contributions". The combo of being firm about our process / procedures, and gentle with how we interact with each other (not immediately assuming ill-will or malice, as I so often do when I see such things) is a great approach to aspire to achieve. I generally see our core maintainers doing an amazing job of finding this balance. May we all strive to live up to the standards they're setting... |
| dww |
@Spokje I used to help maintain all the code that powers d.o. I no longer directly do. But (at least while we've still got a d.o issue queue at all and haven't completely moved to Gitlab for everything), it's definitely still possible to change such things. Mostly that happens in the #drupalorg and/or #drupal-infrastructure channels. Neil Drumm is the primary person on the DA staff who approves such changes. There's a whole process for getting a d.o sandbox dev environment. I'd be happy to help on any of that. |
| dww |
However, the original justification for defaulting to credit for non-patch file, too, was to cut against the perception / assumption / belief that the only kind of contributions that "count" are in the form of code patches. So we wanted to encourage folks to upload screenshots and other files, too. That's real work, real contributions. Or at least, it can be... |
| Spokje |
Yeah, stuff like this is always a double-edged sword. You don't want to make it worse. (edited) |
| dww |
For a very long time, "talk is silver, code is gold" was the a motto of the Drupal community, much to our detriment. (edited) |
| Spokje |
Fully agree with that, just wanted to get some input on my "hunch/gut-feeling/whatever" and a general interest in how these things work behind the scenes on stuff like this on d.o.Thanks @dww for the insights and clear explanations. (edited) |
| dww |
All that said, I regularly find myself thinking the default behavior of the issue credit system is weird. Someone who left 30 detailed review comments over the life of an issue, shaping the course of how it went, but not uploading any patches at all (to remain elibible to RTBC) will get buried as the 18th contributor to fixing something that 17 other people uploaded a single iteration of a patch on... That's not really fair. It also doesn't really matter. Our commit message format is so weird and unruly, the order of that huge block of usernames at the front of the message is sort of irrelevant. |
| dww |
semi-off-topic plug for #2802947: [meta] Use the Git commit message format from AngularJS ;) |
| larowlan |
I think both of those will probably go out the window if we go full gitlab |
| dww |
So we're doomed to have commit messages that you can't scan to figure out what the changes actually are forever? ;) |
| dww |
@larowlan Would you be willing to clarify what "both of those" you mean? |
| larowlan |
if we adopt gitlab without customisation, then our commit authors would likely be those who worked on the patch right rather than in a commit message? like symfony etc |
| dww |
Don't we squash commits when merging MRs? |
| dww |
What's gonna be the format for those squashed commit messages? |
| larowlan |
:shrug: don't know sorry, but I'm guessing it will require manual intervention by the committer because we're talking about vanilla gitlab |
| dww |
I think it's going to be a disaster if we go full wild west, with no conventions on commit messages. And, we're getting way off topic for this thread. ;) My bad. |
| larowlan |
there will need to be a convention, agree, but I don't know what the safety rails will look like relative to what they are now |
| dww |
I'm honestly considering getting up to speed on Ruby development so I can contribute patches to gitlab to make it more friendly to some of the collaborative models we've grown accustomed to over so many years. I'm really sad that Gitlab doesn't let anyone other than the original submitter edit an issue. Going back to the dark ages before we collaborated to have an accurate issue summary is going to be a real shame... (edited) |
| Paulo Henrique Cota Starling |
As @dww pointed, and I agree, the only way people stop adding pictures to issues without any reason is if before a maintainer fixes the issue, he/she uncheck the issue credit for those people who just added a screenshot unnecessarily.It is really unfair when you work in an issue and you don't receive the credits because you don't post any attached file but you did a review and someone who just attached an unnecessary image receives credits.When I work in an issue I try to add something that will help the people that are already working on it so it is very frustrating when you see someone receiving credits for nothing and the person who worked on it, doesn't receive. |
| larowlan |
there has been a lot of freezes lately, between security releases and 9.2 beta/rcs |
| larowlan |
we're out of freeze at the moment, so need to find some time to address the backlog |
| larowlan |
things you can do to help are:review RTBC issues to make sure they actually are RTBC (often when I look at the RTBC queue, 50% of items are not, e.g tests for bugs, issue summary up to date)spend some of your karma pinging me here. by participating in core initiatives/queues you build up some karma. not every maintainer feels this way. but I'm keen on smashing bugs |
| larowlan |
cc @Spokje |
| Spokje |
tips hat @larowlan (edited) |
| Spokje |
Since I don't have a lot of free time on my hands currently, I at least try to have a daily look at the 3 oldest RTBC issues in the Core queue.Checking if:The patches/MR still apply (you'll be surprised how many RTBC patches somehow aren't retested 2-daily)The version of core the patch/MR is retested against matches the Version of the issue. (You'll be surprised how many 9.3 issues are tested/build on 9.1/9.2)(edited) |
| dww |
@Spokje Note that some maintainers look at the oldest RTBC issues first. So if you ping one of them, you run the risk of resetting the 6 month counter for that issue to be seen again. ;) Of course, if it needs a comment (re-roll, status change, etc), you gotta do what you gotta do. But if you comment with "why hasn't this been committed yet?", you can inadvertently delay it even more. ;) |
| Spokje |
Gotcha (especially on that last one :innocent: )Although depending on that system is already fragile, not documenting that system makes it even worse IMHO.(If there is documentation on that, I completely missed it and would be happy to be pointed towards it) (edited) |
| dww |
It's not an official, documented policy. Just something I've gleaned from hearing core committers discuss their process over the years... |
| larowlan |
the order I work in is, stuff people asked me to look at, oldest to newest (skipping stuff that's not in my purview like css/themes) |
kim.pepper, larowlan, gaurav mahlawat, mohit_aghera, Griffyn Heels, Kunal Kapoor, Spokje, dww, jibran, Neslee, anmolgoyal74, Indrajith KB, lendude, hansa11, Kristen Pol, mansoor20, anjalivijay, Paulo Henrique Cota Starling, ambermatz, quietone, Michael (g-brodiei)
Comments
Comment #12
quietone commentedComment #21
quietone commentedComment #22
quietone commentedStill to do: credits and look for any todo items
Comment #23
quietone commentedComment #24
spokjeRemoved double #10.
Comment #25
quietone commentedStill need d.o names for two people, I have added this to the Issue Summary todo.
Setting this to NR.
Comment #26
guilhermevp commentedI'm not sure, but did I miss the timeframe of the meeting?
Comment #27
kunal_kapoor commentedComment #28
kunal_kapoor commentedComment #29
gauravvvv commentedComment #30
quietone commentedThere has been a bit of a change in the workflow for the minutes. When the minutes are set to Needs Review, it is to note any changes that may be needed. Typically, that would be to add todo items (I do try to update that) or maybe adjusting credit. The minutes will be marked fixed, after approval at the next meeting.
@guilhermevp, probably the easiest way to check the date and time is to go to the Bug Smash Iinitiative page on d.o., the link is in #bugsmash channel topic.
@kunalkapoor and @Gauravmahlawat, Did you intend to make a comment?
Comment #31
spokje@quietone: I think what @guilhermevp is trying to say is, he replied in (some of) the threads of the meeting, but his comments (and presence) isn't in this meetings minutes.
I think the threads are open for 24 hours after the meeting starts and he (just) missed that cut-off time?
Comment #33
quietone commented@Spokje, thanks for the clarification.
@guilhermevp, yes, the meeting stays open for 24 hours. It is stated in item '0' but maybe it should also be at the top of the IS? I'll bring that up in the next meeting. But I have not always captured the minutes at the 24 hour mark. But I am now trying to do so and to pay attention to the cut off time.
Comment #34
quietone commentedComment #36
quietone commentedComment #37
quietone commentedAdded credit, removed the todo item.
Update the todo list.
Comment #38
quietone commentedNo changes to these minutes requested at the following meeting.