On Oct 20, 7:19 pm, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > What's frustrating, though, is hearing that you have a > problem with our workflow without any concrete suggestions > to improve it or offers of assistance. There's a general > theme underlying most of this "angst" (as you call it): > the tone implies that you're somehow entitled to our (core > developers) time and energy, when we're just as stressed, > harried, and busy as you.
That's perfectly understandable and well respected. When I referred to "frustration on how contributions or suggestions are managed in Django" and later on to the Linux kernel and its mailing list, I intended to suggest that to an extent, frustration in the community is inevitable - and only then demonstrate the Noble Path Out Of It, for a dramatic effect of sorts :). As for assistance - let me humbly point out that I've written http://code.djangoproject.com/wiki/CollaborateOnGithub precisely for helping people to overcome their git-fear and get a feel how easy maintaining a patch is if done properly. It's also inevitable that the core devs are stressed and busy, torn between real-life needs and the immense energy required to steer a community full of both excellent and - luckily to a much lesser extent - misguided ideas. That stress does sometimes (albeit rarely) result in loss of empathy and gentleness. This is human, understandable and happens in all open source projects. No big deal, but I do share Vinay's sentiment regarding the door metaphor. http://www.ubuntu.com/community/conduct is a good read for any community manager. I generally agree that the current trac + mailing list process is mostly fine (especially if coupled with fleshing out ideas in the wiki that seems to be becoming standard practice now) and believe I'm in no position to suggest improvements - but being invited to it, let me share a few nevertheless (directly borrowed from Debian/Ubuntu, Linux kernel and Unladen Swallow communities). Django Bug Days --------------- At regular intervals, say twice a month on Saturdays, set aside 2-3 hours for IRC-based bug hunting sprints. Devs list tickets that they want people to work on and people are free to suggest their own. Work is done over longer periods, but the bug days provide an occasion to get feedback from the devs. The patches will perhaps not be integrated into SVN but to a branch on a DVCS (see the next suggestion). Added benefit: if nobody shows up, they have no right to grumble on the mailing list :). A DVCS mm-tree -------------- Quoting http://en.wikipedia.org/wiki/Andrew_Morton_(computer_programmer) "He currently maintains a patchset known as the mm-tree, which contains not yet sufficiently tested patches that might later be accepted into the official Linux tree." I.e. there would be a DVCS branch (avoiding the f-word now) maintained either by a core dev or a designated community member that would accept patches more liberally -- but still only patches that are up to Django standards, i.e. tests and docs remain mandatory. This will probably be most effective in context of the bug days, otherwise the management overhead may be too big. Also, that branch would have a few buildbots running tests on it. Code review ----------- Code reviews are super useful, because, in the end of the day, we communicate in code. I have no idea if integrating a code review tool with trac is feasible, so if this looks attractive, the only realistic way to adopt it would be a social-coding-site-centric process - patches remain in trac tickets, but it's highly recommended to maintain corresponding branches in GitHub or BitBucket, so that community members can write code reviews there. Best, Mart Sõmermaa P.S. I won't re-animate the ticket classification argument that created a lot of unintended controversy last year, but I personally think that divide and conquer is the only way to manage the 1700+ open lot. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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 -~----------~----~----~----~------~----~------~--~---
