Consider introducing some sort of unit tests

[gabrielStanovsky]

Since we're fixing bugs now, it's getting harder and harder to tell whether we're messing something elsewhere.
The proper way to deal with this is probably to introduce unit tests with an aggregated set of sentences and their expected OKR structures.
That way we can always make sure these tests pass before we merge a PR.
If we want to go further we can integrate github with Jenkins to run this process automatically.

Part of these unit tests can also include running the evaluations to get an updated metric associated with each PR.

[kleinay]

Problem is, in fixing bugs we are changing the representation we desire. so no "expected" OKR structures can be specified.
We can, However, run an evaluation before each PR to see where it is heading us.

[gabrielStanovsky]

In the new batch from @OriShapira, for example, I fixed a bug which pops up in certain cases, yet I really can't tell if fixing it messed something elsewhere.
I agree that this can be tricky when we change the representation itself.
We can run the evaluation to get a sense if something was completely off, but I'm afraid that won't point us to the specific problem.

Maybe we can talk about it sometimes to see what would be most cost effective.