Hi Russ, On Oct 5, 11:48 am, Russell Keith-Magee <russ...@keith-magee.com> wrote:
> There have been a couple of suggestions recently that the contributing > guide should be distilled into a specific HOWTO for new users. I > suppose the idea here would be for the contribution guide to be the > letter of the law, and the HOWTO to be the spirit of the law -- a > lightweight guide pointing people at some specific activities they > could engage in as a new contributor. I see. Sounds reasonable. I can see that it might be difficult to extract the relevant information from the full contributing guide for newbies, as well as for long time users wanting a quick reference. > > Perhaps we need another triage stage for these tickets, "Needs final > > review" or something? > > That's essentially what RFC is. This is an area where our documented > procedures have lagged behind in-practice procedures, but we've > essentially accepted that once a patch has been written by one person, > and reviewed by another and found to be ok, then it's RFC, which means > a core committer needs to take a look. I'm happy for RFC to indicate that a ticket is ready for final review by a core committer, after being reviewed by at least someone other than the patch author. But, I think there's still a problem of accepted tickets that have a patch with docs and tests and no feedback indicating that it needs improvement, being lost in the shuffle, as well as how and why we ever end up with tickets in this state and how can the patch author get someone to review their work. It could happen that a ticket is accepted on merit, then it gets a patch with docs and tests, and then sits there getting no attention because nobody knows it needs a review. The patch author could just move it to RFC themselves as it had previously been accepted and he or she subsequently added the required docs and tests, in order to get somebody to look at it. But I think this is generally frowned upon and might take up too much core committer attention before the ticket is really ready. It could also happen that a ticket is unreviewed and already has a patch with docs and tests, if it is reviewed by a core committer (or not) and "accepted" without feedback about any necessary improvements, shouldn't it have simply gone straight to RFC instead? What should the original patch author do when his or her patch with docs and tests is reviewed by someone else and moved to "accepted" like this? There's no feedback that they need to incorporate into the patch, and they can't move their own work to RFC, even though someone else has reviewed and "accepted" the patch? I'd like to see the ticket system work smoothly in and of itself, and for tickets to be reviewed without the patch authors having to ask around on IRC or django-developers for someone to take a look. I don't want to make the ticket system too complicated, but I think it is already a bit muddled by determining whether or not a ticket needs review by checking 5 or 6 different properties, instead of a single clear indicator set by the patch author that he or she would like somebody (not necessarily a core committer) to review the work. This could also help in eliminating another problem of not knowing if a ticket is still being worked on or if the patch author considers it finished. > As a general principle, DDN isn't usually a situation where more > information is needed; it's usually just time that is lacking. > > Sprints definitely help push this sort of thing along. However, that's > more because we have two core developers in a room at the same time, > not because of the presence of the rest of the community (although the > community got lots of other great work done). Malcolm and I spend a > day at the recent sprints just doing DDN tickets, and we managed to > clear out quite a few DDNs. We made vague plans to hook up on > IRC/Skype as a semi-regular activity to try and clear out the backlog, > but we haven't made that happen yet. Are at least two core committers required for all DDN tickets? Can a a single core committer make decisions on minor or trivial tickets, and the reporter be given the option to request a vote or further consideration if they feel the decision is wrong (possibly based on lack of information)? Perhaps some of the people who are well known and long standing in the community (but who don't have commit access) could make some of these decisions? Cheers. Tai. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
