>> >>Can you explain me please what does "submitting" means here? >>If you need a person who will say "yes, I need it", I can be this >>person for sure. >>But there will be no use from me if volunteering=programming - I have almost >>no experience here. >> >> > > > However do not underestimate the need for "end users" in various phases. SIMPLY making a request isn't very likely to result in what the end users want even when the programming resources are available. End user input/cooperation is required for:
1) The REQUIREMENTS phase. Not just a roughly specified request but EXACTLY what is this feature supposed to do. Otherwise there is little chance that the end user's expectations and the programmer's understanding of those will match. EXAMPLE (in this case) ---- what do you mean here by "averaging" and precisely what does that mean for budgeting purposes. Speaking as an experienced analyst who has spent decades trying to figure out what the client REALLY wants/needs I have some suspicions here. IMHO a budgeting process has to take into account not only will the averages be OK but that the CASH FLOW will remain positive throughout the period. If not, then this "average feature" would be useful only for the budgeting needs of organizations that can presume unspecified lines of credit. But note that even in this case having a cash flow issue affects the budgeted amounts (you have to pay interest on amounts borrowed to deal with cash flow issues, yes?). 2) DESIGN phase. The analyst will surely have all sorts of "details" questions that weren't settled in the requirements phase, little (or not so little) things that come up when doing the actual design. Now the client can take a break until. 3) TESTING phase. The programmers test till there are no hangs and they THINK the new feature is doing what it is supposed to be doing. But it's the end users and their requirements that matter. However this "user testing" has to be cooperative with the programmers suggesting "odd cases" that the the clients wouldn't have likely thought of on their own. Natural for users to think only about the usual/common cases but in a real project, about 80% of the code is handling all the various oddball situations which can be expected "only when the moon is in some odd phase" (NOTE: for those of who enjoy the challenge, these are the fun bugs that appear "but the program has worked just fine in production for ten years, why is it hanging now?") SO --- I would say that any users making requests should be prepared to do THEIR part of this should programming resources agree to take on their request. As a potential resource, I will say loud and clear that any willingness on my part to "code something" would be conditional on the requester persons being willing to commit to their part. Michael _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel