On Jun 2, 4:08 am, John Cremona <john.crem...@gmail.com> wrote: > Sage surely benefits from having a very wide range of people who are > developers, ranging in age, motivations, mathematician vs. software > professional, and so on. > > Don't make assumptions about the volunteer mathematicians all being > youngsters! (Some of us are over 50, and, I think, amateurs in the > best sense of the word.)
Very much so. > If contributing to Sage meant always (and only) promising to do > specific things by deadlines, many would (I think) fall by the > wayside, including (probably) me. +1 > >> I think we are. I believe that if there were specific dates for feature > >> freezes, it would be useful to know. I for example have a lot of tickets I > >> need reviewing, which has become increasing difficult to get done since > >> sage-solaris was created. Should I try to badger someone to review them > >> tomorrow, since the release will be made Thursday, or I should not worry, > >> since no releases will be made soon? I think the best policy, given the current state (not necessarily best overall), is to have a few reliable people who are knowledgeable about your type of ticket, who care at least a little bit about that type, and whom you trust to give good feedback even if it means "needs work". For better or for worse, there are always more tickets ready for review than people to review them - it's probably human nature ;) but I think honestly also it's the fact that many of us feel we would be doing a disservice to review most tickets, due to ignorance or lack of experience in those areas. But there are some good 2-5 person teams who put in very high quality stuff. I think there are enough people interested in and reliable with the build system/env. variables/ etc. that it would be easy to have an informal list of people who would review them. > >> I believe there is far too little time between a release candidate and a > >> final release - a fact that would be obvious to any professional software > >> developer if a roadmap was published. > > > I'd agree with you here. +1 > > In terms of a roadmap, I think it would be extremely valuable to have a list > > of features that Sage is clearly lacking to be a viable alternative to the > > closed source offerings, perhaps somewhere on the wiki by topic. We need > > something higher level than tickets, but lower level than the mission. This > > has been done haphazardly for some areas, but doing this systematically > > (with a common place to accumulate the results) would be very valuable. This > > has and will happen, to some extent, as part of grant proposals and sage > > days planning. The combinatorics group is a stellar example of this: > >http://trac.sagemath.org/sage_trac/wiki/SageCombinatRoadMap. I'm not > > convinced that tying things to specific milestones/timelines will be as > > realistic given the dynamic nature of the developer base, but setting goals > > for specific Sage days, or "big" releases like 5.0 makes a lot of sense. +1 - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
