> Yeah... it's all things that one of the project leads or another has insisted on in the past.
Note that rebasing vs merging has been insisted on in the past by our project lead, e.g. https://groups.google.com/forum/#!topic/sympy/MnlVfmYYMio My email simply reminded us of that and strengthened the wording so that it is clear. > my nitpicking and bikeshedding is just a mirror of what I get from the project If that is what we do, the maybe following the project's lead isn't good. Why not be the force that helps reduce the time wasted over less important details instead of the opposite? Maybe you could focus your energy on purging and rerouting frivolous conversations instead of fueling them to grow larger and longer. > Oh, and all of this bikeshedding and sidetracking discussion while I'm waiting for the really interesting stuff to even get discussed We are all thinking the same thing, yet we must disagree on the sources of these discussions. Our mission is to make the best open source full featured CAS...under some constraints: 1. Most, if not all, of our developers are volunteers. 2. We reach consensus on decisions among core devs (ideally all devs and users), with a fall back to the BDFL model when decisions stall. 3. and more.. For #1 we have to all be extremely considerate of others time. Everything thing you request from another person should consider their time. If you can help minimize the time they have to invest by giving your time or other resources, then you should do that. Each and every email, comment, and request you send takes time from a volunteer that they'd likely prefer to have for themselves. For #1 we also have to be very considerate of motivation and moral. We don't get monetary rewards or many other traditional compensations for our time. We can offer reputation, friendship, networking, altruism, community, etc. These may or may not be valuable to contributors. Most volunteers will not put up with much BS for the rewards we can offer. So we need to always think about how to maximize the benefits we can give, minimize the BS, and whether this can retain motivation for the time and energy each contributor provides. We also need to maximize our number of volunteers for the reason that "many hands make light work". We pride ourselves on having more contributors that provide substantial contributions at any given time than many other scipy projects. We'd love for this to increase more but this makes #2 more difficult. This also requires that we lower the barrier to entry as much as possible, without compromising the general project quality. For #2, I want to remind everyone that consensus doesn't mean that you have to 100% agree with every decision that is made. It also doesn't mean that you should bog down or halt decisions that you don't 100% agree with. We always have to keep in mind that consensus is for the group's needs, not the individual's. A participant in a consensus based decision should start with thoughts like: "What outcome will best serve the *group*?", "Will this decision deter or slow us from furthering our mission, given the constraints?", "What is the minimum I can personally accept and deal with so that we can move this decision forward (not backward!)?", "What is the essence of this discussion, i.e. the most important thing that needs to be decided?", "Is this decision essential to furthering our mission?". If we all keep these things in mind, then the trivial discussions will start to disappear and we will collectively focus on moving forward with minimal overhead. We should all practice at identifying things that are causing decisions to stall/halt and pointing them out so that we can get over the humps quickly and efficiently. When I think about this merging vs rebasing issue, the essence is that we want to minimize the barrier to entry given that we currently use Git/Github. Merging is by far a lower barrier than rebasing and we've had numerous PRs stall over this, much confusion in PRs, and loss of new contributors due to it. Is instituting merging worth some of us having to view a less than perfect git history and a having a little more overhead on git bisecting, for example? In my eyes, and I believe everyone at the SciPy BoF, the issues you bring up are extremely minor when compared to the problem we will solve by strengthening this guideline. A perfect git history and easier git bisecting are not essential to our mission, but increasing and retaining contributors is. Jason moorepants.info +01 530-601-9791 On Mon, Jul 13, 2015 at 9:29 AM, Joachim Durchholz <[email protected]> wrote: > Am 13.07.2015 um 16:39 schrieb Jason Moore: > >> I apologize for insulting you. >> > > Okay. > > > I have no intention of insulting you but I find that > >> the majority of your responses to emails/pr/issues are in essence nitpicks >> or bikesheds. >> > > Yeah... it's all things that one of the project leads or another has > insisted on in the past. > Personally, I'm happy with whatever the bikeshed color is, but if the > majority said "yellow" then I'm telling newbies to do yellow. Except it > doesn't help if one project lead steps in and insist on light brown, > because that's how he perceived that color (and sometimes a project leads > insists on green, because he doesn't remember, or cares more about personal > pet peeves, or both). > Things are getting even worse if somebody tries to clean up PEP8 stuff, at > which point somebody else steps in and declared that it's bad for the git > log. So I take home that the git log is important (which I can agree with), > and now I see a policy for merging which is bad for the git log... really, > this all is driving me mad. > > Oh, and all of this bikeshedding and sidetracking discussion while I'm > waiting for the really interesting stuff to even get discussed, let alone > merged. > So there's that source of frustration for me - my nitpicking and > bikeshedding is just a mirror of what I get from the project, and trying to > make it (mostly) unnecessary to do PEP8 cleanup but now *you* are > dissatisfied. > > Plus, there are things about SymPy that are harder to fix and more > difficult to reach a consensus about than PEP8 or even git workflow, but if > we cannot get the project itself to stick with these simple things, I have > little hope that the complicated stuff will ever get done in a sustainable > fashion. We already have lots of orphaned code (I wholeheartedly agree to > the push for module maintainers, though maybe "coordinator" would be a > better term - as rightfully said, it's not important that the person in > charge knows everything, knowing whom to ping in case of trouble is more > important). > > > I feel exhausted reading most of them and at this point I try > >> to avoid reading your responses at all. This last response to my email, >> which was simply a reminder of a current "policy", irked me enough to >> finally say something more explicitly. >> > > Well, the announcement irked me because > a) it got some facts wrong, > b) it presented a conclusion that I consider less than ideal, > c) it hinted at a discussion with no way to check the discussion and see > how the consensus was reached, iow it was a decree "from above", and hence > not open to revision and soon going to be gospel to be followed by the > letter instead of guidelines where people have a chance to know when it's > appropriate to follow them and when not, > d) it's very strong language that massively overstates the policy. > > Not in order of relevance, I think (b) was least relevant to me. > > I am happy to have a conversation in whatever medium you want about this >> once you are willing to. I do think we can come up with something >> worthwhile, as we are both reasonable people. >> > > I have started questioning whether SymPy is worthwhile for me. > Partly for reasons in the project (the above is an overly long exposition > - sorry for that! - of a large part of them), partly for reasons on my side > (other projects, dissatisfaction with Python as a language, that kind of > stuff). > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sympy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/55A3E779.5000305%40durchholz.org. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1AgVQsVM%3DrYY-QLj7wL02SD4Xi42z3sry3PT9kPVokJDTw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
