• comma
• Workbench
• ArbiterSupportComm

Arbiter - Support Communication Tool Proposal

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:

• 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