Hi, Bill Hart posted this to the flint and bsdnt lists, and it's also relevant to sage-devel, since though we have "SEP's" = Sage Enhancement Proposals, we rarely use them. Maybe we should use them much more and make things much more systematic. For example, it would make a lot of sense to have a SEP about making a "library version of Sage".
---------- Forwarded message ---------- From: Bill Hart <[email protected]> Date: Mon, Nov 1, 2010 at 6:30 PM Subject: [bsdnt-devel] White papers To: flint-devel <[email protected]>, [email protected] Hi all, I'm writing to flint-devel and bsdnt-devel as the issues are relevant to both projects. Apologies for any duplication. I'm becoming convinced that eventually we'll need to have some form of "Enhancement Proposal" system for flint and bsdnt. For an example of what this is, take a look at the Scheme Requests for Implementation (SRFI), e.g: http://srfi.schemers.org/srfi-4/srfi-4.html Many large projects have such a system, including the Linux kernel, Python, and many others. In fact, I would argue that they become important to any sufficiently serious project. Even for small projects, they can serve a use (when used judiciously): * They provide information to potential developers about what major features are currently being worked on. * They expose major new functionality to careful scrutiny and comments by experts before the proposed feature becomes part of the project. * The can serve to attract new developers who want to work in a team to implement various proposals they get excited about. * They serve to identify the developers working on any given component under active development, when they started, what progress has been made and where they are going with it. Secret development projects always have to exist for various reasons, but sometimes it is better to have a small number of RFI's as well for more public projects/modules. I definitely don't want to get bogged in bureaucracy, but it might be fun to write these things some times. For example, someone just requested a module for polynomials mod large moduli on flint-devel. As it happens, such a module has been under development for a while. But this would ordinarily present a great opportunity to write a short (say 2 page) white paper describing how such a module should work, what functionality it would implement, what algorithms will be used, and invite comment from the original requester. I think these RFI's should be limited to the level of full modules or very large subprojects only in bsdnt and flint2. In bsdnt we might have RFI's already for: * A high level memory managed module for integer arithmetic (fmpz or something equivalent) * A module for low level multiprecision floating point arithmetic * Factorisation of integers?? all of which have been requested. For flint2 we might have RFI's for: * Matrices over Z/pZ for small p * Matrices over Z/nZ for large n * Some other things that have been suggested lately all of which are currently under development. I would envision the main developer who is going to work on said module would write the RFI doc and keep it up-to-date in keeping with comments made on the devel list in response. I don't think there is any point in writing RFI's for modules we already have well under way, and of which there is plenty of discussion going on already. This would be for future things. How do people feel about RFI's? Do you see value in them? Would you personally write them and maintain them if you were excited about working on a new module? It almost seems to happen anyway on our devel lists, but in a haphazard sort of way which is difficult for potential users/contributors to keep track of. But I'm interested to know how current developers would feel about writing these. Would it just put you off? Bill. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
