I would also suggest cleaning up the existing set of easy issues where the issues was tagged as easy initially followed by discussion about how the though easy has other concerns like backwards compatibility due to which it can't be merged. It's getting hard to get more easy issues and what could seem as an easy fix might later expand into a discussion that the beginner might not have enough context to answer and in that case the easy tag should be removed. It's even harder over realizing when to fix it by myself or tag it as easy for someone to fix it because if it's fixed by a regular contributor then there could be a thought that I myself could have done it since triaging itself is a difficult work.
I agree that many issues need to have the 'easy' tag removed. There really isn't a stage on the tracker for 'in discussion' or 'deadlocked'. I think 'languishing' was the closest status for that. When I've added 'easy' to older issues in the past, I try not to do more than one or two a day. That way, the nosy list doesn't get spammed too much and there aren't too many issues that float to the first page. Maybe something similar for removing the 'easy' tag? Only change a few day, but also leave a comment summarizing the discussion (if it had been long), or just saying "X core dev thinks it should be this way and Y core dev thinks this, so until that is resolved, this is no longer an easy issue." A comment would help because you would have done some research, so that communicates to others what you found out about the ticket.
I certainly didn't intend for my first week as a core dev to be about trying to change the workflow, so apologies in advance if anyone thinks this is too drastic.
I would also recommend waiting for a core dev or someone to provide some feedback or confirmation on even an easy issue's fix since it's easy to propose a fix to be later rejected due to various reasons resulting in wasted work and disappointment.
Agreed, but perhaps the most helpful way to do that is to propose the fix in a comment on the bug tracker and then, if a core dev or expert says it's a good idea, then move ahead with it? Although, just recently for IDLE, I made a suggestion on the tracker and then my code wasn't what Terry expected, so sometimes the clearest explanation *is* a code change. But, for any change that someone will spend some time on, then there should probably be consensus first.
PS : Using mailing list for the first time apologies if I have done anything wrong.
You did great! This topic was my first post too, so I know exactly what you mean. :-)