“This makes the Mint’s task read-only, the Mint only checks the spentbook for transaction commitments for each input DBC to verify that all inputs are committed to the same transaction and validates the transaction balances.”
Key functionality, PR from David Rusu now merged:
Looks good overall. There seems a tension between tense of spendkey and spentbook. Maybe we should just standardize on spent to avoid confusion.
Those are the kind of things my OCD mind likes to see. 
But I bet it actually is useful when it comes to code.
Also a cascade of PR’s merging quickly in the main repo after several days of turbulence. 
Have you noticed those annoying free thinkers who like to type spendbook rather than spentbook!
Actually I was doing that myself at first. I wonder which will win.
The d-loving heretics will be rounded up and dealt with. there will be only one winner
So Declared by the old guard
Maybe they are German.
German’s cannot hear the difference between a “d” and “t” at the end of a word.
(obviously not all Germans)
updade
spent has a finality about it.
Correct me if I’m wrong but from an organizational perspective it’s a lot more efficient if such a list did exist though? How do devs assign and schedule their workload otherwise?
They have their own way to manage tasks. You don’t need a MaidSafe agreed view that covers everything. You are given an area of responsibility and work informally with whomever you need to, to establish the details and parameters. You get on with it and communicate with those who need to understand how your work is proceeding.
All this can work efficiently in a small team. In large teams you can’t do this, or where there needs to be tight budget and timescale management. Here neither apply, so a small team can work informally and much of the task management can be done by the individuals or pairs working in a particular area, maybe never written down.
I’d be very surprised if there was one person with a list of everyone’s tasks (because to be useful each task would have to be defined in detail, not just a handful of words). But even if there was, publishing it would create unnecessary work and slow the developers down as I’ve explained.
Hope that makes sense.
My understanding is that at this stage of development the list of features or rather requirements is fairly short
With the exception of the last two points the rest are all closely connected mainly revolving around a small number of building blocks, particularly the sending of messages between nodes and AE. So progress in achieving one milestone (eg clients connecting reliable) will be immediately transferable to other areas because of this building block approach.
With each building block being worked on by an individual or two, progress, when it happens, can be rapid, but because progress is not linear or particularly predictable it’s not amenable to a tickbox approach.
Makes sense, thank you for the detailed response.
John, those are requirements/specification rather than tasks. The key difference here is that some requirements might be ticked off as you go, but many will only be met when the network is finished. Whereas tasks can ask be ticked off as they are completed so give a better sense of both progress and remaining work to completion, although neither are very reliable.
I’m not sure how communicable the tasks would be, in that most of them will be bug fixes. Therein lies the problem.
I like the sound of “spendbook” better but note the finality to a “t”. Think of it in the abstract as a big “data base” of transactions and you might like the spen-db-ook too.
Enough of this pandering to the D people!!!
Let them learn their place and realise it can only ever be SpenTbook signifying past tense. Done and dusted. These transactions are in the pasT.
Is that really true though? Not so sure here as I’ve skimmed the reading while multitasking. The clients write to the SpenDBook first, then need it validated before they can spend it. So spenD is a better descriptor, no? Only after validation is it done and dusted, right? SpenDBook it is.
I hate it when bastards bring logic, reason and facts to an argument.
Yes it is true. It’s a list of spent transactions, not a list of dbcs that clients are able to spend.
Transactions that are written to the spentbook are now spent. The stamp of approval that comes after that from the mint only adds authority, but does not change it from being spent. Once the client writes to the spentbook there is no second chance to spend it differently, so it’s spent.
The literature for dbcs uses spendbook, I personally feel it’s a spentbook, and the difference is important for building an intuitive understanding of what this thing is.
Spend is a verb. It’s implying that the book lists something that’s ‘in motion’ or ‘happening’. This isn’t the case here.
Spent is an adjective. It’s describing the state of the data. It’s in the past, spent, not able to be changed, which is an accurate description.
To use a bitcoin analogy, spendbook would be utxo (ready to spend, able to spend etc), which the dbc record is not doing. The spentbook is any transaction that’s completed, ie the bitcoin blockchain not including utxo. It’s an important distinction since it affects how we can use the data, eg can it be used for an audit or not? Can it be used for linking history or not?
Maybe the “spendbook”/“spentbook” term could be replaced with something more descriptive altogether. The writing to the book by the client definitely infers a kind of journal or ledger but then the authorization to disseminate funds goes a little beyond a simple journal/ledger, it entails some kind of disbursement mechanism, if that is included in the spendbook’s realm of responsibility.