= Arbiter - Support Communication Tool Proposal =

[[comma/Workbench/ArbitrationTool|Specification]]

Eva Stöwe, 20160630, to arbs, supporter, SAs, board, well and teams:
 {{{

Hi arbs, supporter, SAs, board, well and teams

I want to propose an idea to you. My aim is to solve three issues with
it, even as it will sound small in the beginning and too big in the end.

Problems to solve:

1. goal: add missing support-arbitration communication tool
2. goal: revive software area
3. goal: move to a new software

I would like to propose the following:

Deleting accounts is now done by support without much arbitration
interaction. But the DRP tells us that one may not ask for termination
of membership as long as one is involved in an arb-case.

For this all delete procedures somehow stated that support should check
this somehow, but we have no technical way to do this. So it would be
good to have a tool for this, so that

a) arbitration could add the names and email addresses of people
involved in a case and
b) support could enter a name/email of someone who wants to leave for a
case number

If there is a case number support could check if it is open or closed.

That would be the absolutely basic functionality.


Well it is missing and we need it - so I would propose to ask if people
would write something like this, including proper specification and test
cases and all. I would ask it to be modular and with multiple layers
(db-tier, core and user-interface/web-tier), one module should be
authorisation, db should have a table for arbs/support and possibly
other roles, stuff like this.

I believe it is small enough that there could be someone interested to
do it, when I provide a basic specification and am available for further
details in the spec.


If we have this, we can add additional functionality. Like being able to
close cases. ... Or to provide the functionality to send automated mails
with queries approved by arb & SA ... Or for arbs to look up
CCA-acceptance or primary email addresses to enable them to write proper
init mails.


The basic features will be able to be run standalone. Which means it
does not have fulfil the requirements to be moved to critical server. -
Later features may include that or not.


What I aim at is something that is useful right from the beginning ...
and may be able to take over a lot of the functionality of the current
software step by step. In a modular way so that some features could be
replaced later, again. For example one could want to change the DB at
some point or the user-interface ... or separate the arbitration stuff
into an arbitration tool.

I believe if we ask people to help us with something small we will get
some people who want to do that. And we can ask them to do it properly
so that it has specs and tests and documentation as much as possible.

By getting things running in a productive and useful manner, soon, I
hope we can keep those people interested to code. I am quite sure that
there would be such people.

Some of those people could be the kind of people that we would like to
have as software assessors. By starting with comparable uncritical
stuff, and leaving the critical stuff with the current software for some
while, we can build them up step by step, as well.


If it does not work, we at least would have some useful tool, that we
are missing for some while.


Well, I probably will address people to join into something like this,
soon. ... Will have to write the outline of a spec.

Comments/help would be appreciated.

Uhm, I would chose Java or something including Java, but we can discuss
that (have some arguments for it)

Kind regards,
Eva
}}}

Karl-Heinz Gödderz to Eva Stöwe, 20160701:
 {{{
to open the discussion about the proposal of Eva to develop an arbitration-tool, I got some ideas, I want to present.

For the first phase I think it is enough to have a Database-sentence / Table-row containing the following Data:
}}}

|| '''Field''' || '''Definition''' || '''Contents''' ||
|| Case Number || VARCHAR (20) || ||
|| Email-Address || VARCHAR (50) || ||
|| Name || VARCHAR (50) || ||
|| Role || CHAR(3) || ICM→ iCM intermediate Case-Manager<<BR>>CM→ CM Case-Manager<<BR>>A→ Arbitrator<<BR>>Cnn → Claimant nn<<BR>>Rnn → Respondent nn ||
|| Time Enter || YYYY-MM-DD || Time the person in question enters the case ||
|| Time Leave || YYYY-MM-DD || Time the person in question leaves the case ||

 {{{
A possible extension could be to store the reason for Entering or/and leaving the case.
In case of CAcert Inc. or board is involved, it could be necessary to have a field / fields that name(s) the person in charge.

This my thoughts for a first Definition. 

Also if Eva votes to use java, it could be considered to realise the access with PHP.
}}}

Eva Stöwe to Karl-Heinz Gödderz, 20160701:

 {{{
I really appreciate it, as it shows me that my approach works and that
people would like to do this.

But I ask you to allow us two other steps prior to entering into a
discussion about ideas about implementation, just to allow everybody to
join in (please do not understand it as if I do not like your ideas,
that is definitely not my intention)

a) to at least write a basic specification and

b) to bring this to a public list to ask others if they want to join in

My reasons are:

a) we want to be transparent and it would be good to not prevent some
possible audit over the software right from the beginning. My idea to
break it down into small modules is that by this we should be able to
describe the requested features easily and quickly enough so that we
actually should be able to have some specification and later
documentation. Because this is mostly missing for the current software.

And while the few words I wrote actually seem to be a good enough
outline of the requirements for your ideas (which is great) we possible
should add some more details.

b) One of the goals here is to bring together a team for writing this. I
posted here, because I first wanted to present my ideas to some people
who already have shown some interest. Or who may want to add some
further requirements or to protest or whatever. We should give others
who are not on this single list a chance to join in.
}}}

Karl-Heinz Gödderz to Eva Stöwe, 20160701:

 {{{
You are right, we/you should present your idea in a more public list.
Will you start the thread in the appropriate list(s)?

Should we discuss previously about the basic specification?
where I thought that specifying the needed data (to be discussed about)
were a preliminary to
go to a more specific evaluation of what has to happen for the wished
functionalities, which are:

to enter data in the database and
to retrieve data from the database

or has it to be the other way around?

about this functions I also have some concepts.

On the other hand, could we create a wiki-page to collect the ideas?
}}}

----

 . CategorySupport