Hello Arnon, let me explain how we operate. First of all we all volunteers so we try not to commit to promises we cannot maintain. For the same reason we do not feel like putting pressure on those volunteers.
web2py evolves more like natural evolution than by intelligent design. If a feature is really necessary than doable, then we do find enough resources to get it done. We do this by small steps and not by large jumps. Large jumps have happened and will continue to happen but in my experience, they do not happen because we put them on a roadmap. In general our evolutionary changes feel the following pressure forces: - they should add functionality - they should do in general way - or they should reduce the code size - they should make the code faster, never slower. - must be backward compatible Very few of the patches I receive have been agreed on. People play with the code, find ways to improve it, email the changes to me. I check the 5 rules above are met, maybe do some quality control on the code, and eventually approve it. If something is needed, than there should be enough people working on it already. If there is no critical mass working on something than probably, there is not enough interest. We have polled people before but it was always about how to implement a new feature, not whether to implement a new feature. This is because developers do want feedback from the users but if the needs do not come from developers, things will not get done. There are other models. Certain features have been sponsored. For example the SahanaPy Foundation has payed developers to add some core features they needed, including for example the geo dal. I think a roadmap will be useful. It should contain list of desired features. A discussion of feasibility and a clear statement from me (and other core developers) about priorities. But it should not contain deadlines. I do not think the roadmap should come from me. I am satisfied with what I have. I think it should come from users, so that I and others learn more about users needs. Massimo On Saturday, 25 May 2013 15:22:24 UTC-5, Arnon Marcus wrote: > > Ok, I get it now. But still, the most efficient way would be that the > people with the most experience in a given area, would be the ones to > maintain it. You are putting a restriction on scgedule that does not apply > here. Within a time-frame that is smaller than what an experienced person > has available, than you are right. But as you said, web2py does not have a > formal release-cycle, and there is currently no incentive in existence for > defining one. So, in other words, your example is correct, only when > applied to a scheduled-project, which web2py clearly is not, by your > standards. So in that case, experienced person B would be most suited for > doing both assignments. The overall community-time invested would be only 4 > hours. It may take longer to complete schedule-wise, but that has no > relevance to an un-scheduled project. It may take Massimo even a few months > to get to that, for all I care, it would still remain more efficient. -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
