Evaluate courtbot from Anchorage

[ying1]

Task:

• [ ] Determine overview information relating to courbot from Anchorage's court bot: https://courtbot.codeforanchorage.org/ at https://github.com/codeforanchorage/courtbot.git
• [ ] Determine how different they are from the Tulsa courtbot project (maybe compare once evaluation in #2 is done)
• [ ] Evaluate whether a similar approach would work for San Jose's courtbot (goes for #4)

[rkiddy]

FYI: here is the project-fork hierarchy of the courtforamerica/courtbot project on github. I removed all names that sounded like individuals rather than brigades. The top-level project has not been changed in 7 or 8 years. Most of the others are a year more recent than that.

One of the difficulties I am seeing in decided on a re-use case is that none of this has been kept fresh.

And we see some running implementations. We should ask how much activity they are getting, how many notifications they send out per month.

codeforamerica codeforamerica / courtbot
--> code-for-england code-for-england / courtbot
--> code4sac code4sac / courtbot
--> codeforatlanta codeforatlanta / courtbot
    --> codeforanchorage codeforanchorage / courtbot
    --> CodeForAsheville CodeForAsheville / courtbot
    --> codeforbcs codeforbcs / courtbot
    --> codeforbtv codeforbtv / courtbot
    --> codefortulsa codefortulsa / courtbot
        --> codelahoma codelahoma / courtbot
        --> opensavannah opensavannah / courtbot
--> codeforbirmingham codeforbirmingham / courtbot
--> OpenSantaRosa OpenSantaRosa / courtbot

I like the name "codelahoma", particularly.

[rkiddy]

FYI, this is the table schema used to store hearings in the AK system:

CREATE TEMP TABLE hearings_temp (
            date timestamptz,
            defendant varchar(100),
            room varchar(100),
            case_id varchar(100),
            type varchar(100)

Not surprisingly, this is similar to the MySQL stricture that I set up:

CREATE TABLE `court_cases` (
  `pk` int(11) NOT NULL,
  `dept_pk` int(11) DEFAULT NULL,
  `case_number` varchar(31) DEFAULT NULL,
  `parties` varchar(10240) DEFAULT NULL,
  `scheduled_time` varchar(31) DEFAULT NULL,
  PRIMARY KEY (`pk`)

So, instead of a room, I have a link to the department. And my link to the department links the case to a court.

They have a separation between the loading of criminal cases and civil cases. They seem to get different things from scraping these two:

const csv_headers = {
    criminal_cases: ['date', 'last', 'first', 'room', 'time', 'id', 'type'],
    civil_cases: ['date', 'last', 'first', false, 'room', 'time', 'id', false, 'violation', false]
}

So, it seems that the "type" column has some extra info, not just "civil" or "criminal". But, ignoring this, the data looks functionally the same.

[rkiddy]

FYI, EugeneY at code for BTV is using the UI of Anchorage's app, but does not like python so much and so is implementing it in Node JS and is not using postgres but rather a NoSQL solution.

I am sensing that if you want technical volunteers to implement something, they will not actually want to re-use anything. It is much more fun to do it yourself.

[ying1]

I think, learning how to adopt to an existing code is a good skill to have... as most of times at work - you don't really get to build code from ground up.

[rkiddy]

I agree. It is most useful. But it is clearly not the norm for efforts at CfA brigades. Further, it is a bit more difficult to design things to be re-usable and re-configurable. This also does not seem to be a common practice among CfA coders.So, we can think that this would be better but it is not what we get.

[ying1]

Closing. Thanks for evaluation.