This is probably definitely too long, but you can safely skip the first parts to the cycle ticket.
Background
Being in between jobs, I thought to stay “in the loop” by contributing something back to Django. Although I have been using it for the past five years, it was mostly backend related. So there are many parts of the framework I haven’t used. A good time to change that.
What to work on
My plan is to start small and to find some tickets I could contribute to. “Easy pickings” are hard to find and so I used the “vulture” method that @sarahboyce proposed. Tickets that are accepted, haven’t seen any update lately, have already a patch, which needs some improvement to get the ticket over the finishing line. With these tickets I have to understand the problem, the proposed solution, the fix itself and what is still missing. From the comments I try to see if the problem is still a problem today and if working on the ticket would make sense. Ideally the missing bit is not too large and complex and I can create a small PR for the ticket. All that said, in the end I’m not the initial advocate for the change.
the cycle ticket
The ticket was opened 16 years ago. As far as I can see the `cycle` tag got last changed 13 years ago by adding the `silent` feature to it. Up to now people are using the `cycle` tag as it is and the ticket hasn’t seen any frequent comments with the question for when it will be fixed. So either the problem isn’t very big or people are happy to use workarounds or the `cycle` tag is just not so often used anymore as it might have been after its creation. I can’t tell.
After asking “Is this still considered a desirable feature?” the answer was “Yes, IMO nothing has changed.” . But maybe this was a classic miscommunication. Because I was referring to the original problem statement and not to the last comment saying “… however this is a good feature, and the current API is kind of silly. This is accepted, provisional on creating a new, more sane and consistent syntax, to be placed in the future module.”
So I moved forward, implemented a fix, created a PR, was wondering how I could attract reviewers to it and here I am.
If the ambiguity of the new syntax prevents the PR to be accepted, then I can understand and I’m happy with that. I can withdraw the PR, have learned a lot along the way and move to other topics.
I wouldn’t want to put more effort into something brand new like `cycleseq`, because, as I said, I think there is negligible demand for exactly that. And just to add a new tag to cover some edge case, that most likely will be very rarely used, doesn’t sound right to me.
And I really don’t want to sound negative. I strongly believe that the code not written or merged is as important as the code that gets accepted.