[Skip] > Okay, that got a response! If bugs are submitted without > assignment, we should probably establish a formal triage system. It > could work on a rotating basis (weekly?). Still, I think there has > to be some way to work through new bugs quickly to either get them > advanced quickly or ejected from the system. Sorry, since we're all volunteers here, I don't see how a formal rotation could work. Since you're a volunteer, I don't feel comfortable to tell you to do something. We all know how to do triage on bugs and patches, so I assume that if you have time, you'll do it without me telling you so. SourceForge has plenty of annotation capability so there's very little risk of duplicate work. > As an "official" developer, I would find it useful to get a summary > mailing weekly of stuff that's assigned to me. I have no particular > other reason to login to SF. When something's assigned to you, you get an email. Isn't that enough? Jeremy has a script to send out reminders to everyone that he used to run weekly, but it doesn't seem to have any effect on the speed with which people look at bugs. > Guido> Assigning to a random *active* developer may seem to > Guido> work, because if this developer isn't the right person, > Guido> he will quickly do triage and pass it to someone more > Guido> appropriate -- or simply unassign it if there's nobody > Guido> appropriate. But if the person is away (e.g. on vacation > Guido> or on an extended business trip), the other developers > Guido> will be less likely to pay attention to the bug than when > Guido> it's not assigned at all. > > This suggests that it would be useful if SF allowed people to > temporarily inactivate themselves. Is there such a feature? (I > didn't see anything, though I was just able to change my timezone > from US/Eastern to US/Central. woo hoo!) There's no such a thing. I suppose you could remove yourself from the list of developers, and later when you want back on, you can ask to be added back. But that only works for long absences (like several months). > Guido> Playing games with the bug priority to get someone's > Guido> attention is also the wrong thing to do -- only the > Guido> experienced developers should raise the priority of a > Guido> bug, based on its real importance; we have rules like > Guido> "everything priority 7 or higher must be fixed before the > Guido> next release". (Lowering priority on submission is fine > Guido> of course, if you know you have a low priority bug > Guido> report.) > > I don't believe I suggested this as a way to grab peoples' > attention. No, but Jonathan Gardner did that, and really p*ssed me off (he was complaining he didn't get a response to a bug he reported the previous evening). > >> As the Python user base grows I think we do need a way to > >> expand the developer pool without a lot of effort because the > >> amount of feedback is always going to be proportional to the > >> number of users.... > > Guido> I would certainly like to see more applications from > Guido> people interested in getting developer status, even if it > Guido> means I'll have to do semi-formal "interviews" or > Guido> reference checks myself. How can we encourage the good > Guido> developers that exist to help? > > Well, you could always post an announcement on c.l.py. I suspect > you might have an initial candidate in Jonathan Gardner. ;-) Given the fate of his bug report, I think he may be a little green. :-( > Still, I sort of doubt this is how other large open source projects > work. I can't imagine it's a real productive use of your time or > that of other gifted folks (Larry Wall, Ben Wing, etc). I'll do anything I can to get more people to volunteer. But in the past volunteers have always offered themselves, so I have no idea what would be a good strategy to attract more volunteers besides just keeping doing what I'm already doing... --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4