[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tsf-dev] TSF process feedback, part 1: statement graphs and references
|
Sam,
Statement graphs
----------------
...
One gotcha: people have at times imported existing texts into TSF as
Statements, without taking time to rewrite them. One example was a step
by step process where each step became a statement. It might have been
a good process, but once imported into TSF we would see particular steps
out-of-context and they'd make no sense.
One solution is to write an Agent skills for Statements, which guides
people to produce the needed information and checks what is written.
The Hedera blockchain is a great example of this:
https://github.com/hedera-dev/hedera-skills
I was at their hackathon two weeks ago (team Tariff Pilot came joint 3rd).
They even had a hackathon-helper skill that checked team submissions.
It worked really well. Despite knowing nothing about Hedera at the start
of the hack, we+Agents put together an impressive working system (if I say
so myself) in a couple of hours.
https://github.com/Sparkah/hedera
Another gotcha: our graph of statements has become simply too big,
and has too many different owners.
Limiting the size will limit it's applicability.
Some form of modularization is needed.
Many statements in our graph have one or more references. The intention
is to provide supporting evidence for the statement, on the principle
that trust should be based on evidence. The principle is sound and in
many cases this works nicely, but you have to always be asking:
My experience with cited evidence for statements in software engineering
is that it's often unconnected with what is claimed, or is circumstantial,
or the data is poorly analysed.
Bedtime reading: http://knosof.co.uk/ESEUR/
'evidence' also needs to come with confidence bounds.>
...
An illustrative example that demonstrates all these anti-patterns: one
statement said "Configuration of Foo is managed solely via this config
file", and as evidence it linked to a huge config file for Foo.
Good example. Also what are the configuration options and
what is the range of permitted values.
References have another cost, due to the "Suspect item" and "Suspect
link" detection that flags when they change. I'll discuss this below in
the "Modifying the statements" section.
Lesson: keep references to the minimum necessary, and review them
carefully.
Surely it's better to have the references? Not having them is
worse than having too many.
--
Derek M. Jones Evidence-based software engineering
blog:https://shape-of-code.com
