On Fri, Feb 18, 2011 at 11:58 AM, Aaron S. Meurer <[email protected]> wrote: > > On Feb 18, 2011, at 7:07 AM, Vinzent Steinberg wrote: > >> On 18 Feb., 10:49, smichr <[email protected]> wrote: >>> I can't find the message where you discussed a 24 hour wait, VInzent, >>> but I think we could generate some other principles that would help >>> development: >>> >>> 1) Like Robert's Rules of Order, before beginning to make a solution >>> for an issue, seek a "second" for your motion. That affirmation would >>> indicate that someone thinks your proposal for a solution is worth >>> pursuing. >> >> This is a general rule, it correlates with "release early, release >> often". >> >> If you want to avoid "wasting time" (if you want to call it like this) >> it makes sense to speak about your plans with the community. "Getting >> your code in" is relatively easy in SymPy, compared to projects like >> Linux though. >> >>> 2) Ideally, besides a second there should maybe be "thirds": one or >>> more persons that would be willing to review the work. >>> >>> 3) Make a pull request when the work is finished. >>> >>> 4) After 24 hours, or when that pull request comes next in the queue, >>> or when it is agreed that the pull should move forward...respond in a >>> timely manner to keep the pull active. >>> >>> As to the processing of pull requests: if we processed pull requests >>> in the order received or have some mechanism -- push credit based on >>> lines reviewed? -- to decide when one might jump ahead, this would >>> encourage review of existing requests. A pull request mightbe skipped >>> over if the pull doesn't receive response to feedback within a day or >>> some reasonable time frame. >> >> In my opinion, this is a general resource problem of Open Source >> projects. Ideally a pull request would be reviewed immediately. But >> this is not possible due to limited resources. You need to find >> someone to review your work, or it won't get in. Even larger projects >> like Python or Linux suffer from this problem. >> >> We could introduce a more systematic approach, but in the end everyone >> works in his free time on SymPy. When and which patch is reviewed >> depends on occasion and interest of the reviewer. This is not optimal, >> but it is like it should be in such a project. > > I recently had some interaction with the git project. I was surprised to > find out that they do not have an issue tracker. They rely solely on their > single mailing list. If someone sends a patch to that list, and no one > reviews it, then it is lost. To quote Junio Hamano, the git project leader: > > What we do is to take advantage of the fact that issues people do care > about are important ones, and others that nobody cares about are not worth > pursuing. > > In a sense, "people forgetting" is a lot more important than "people > remembering" to filter unimportant issues (issues that are so unimportant > that even the original complainer does not bother to come back and > re-raise it). > > Now in my opinion this isn't a very good system, though it's perhaps better > suited to a larger project like git. In our system, once someone opens an > issue or a pull request, even if no one looks at it for a month, it is still > siting there, and someone might some day notice that it needs review and do > something about it.
Yes, our pull requests system is way better imho. > > The thing is, people review the patches they are most interested in. If > someone creates a patch concerning a piece of code that I have written (like > the ODE module), or some code that I am working on (like integration), I am > much more likely to review the patch. On the other hand, I specifically > don't review patches to things that I do not understand mathematically, like > the quantum stuff, because that wouldn't be fair to anyone involved (all I > could do is see if the code looks alright and if the tests pass). > >> >> It may be possible to make deals like "I review your patch, and you >> review mine". > > Yes, I did this a few times last month when I had all the important pull > requests open. It's a good system that benefits everyone. If two people are > sitting around wanting someone to review their code, the least they can do is > review someone else's code. If this is organized between the two people so > that this actually causes both codes to be reviewed, then it will work out > well. Indeed ---- that's a very good point. Continuing on my email above, instead of mailing me, who don't have any pull requests open at the moment, one should email other people who have open requests in there, and one can easily see who those are. And simply help each other, as it benefits both of them. Very good point. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
