... and collapsed by default.

So that they can be kept on top somewhere when completing a coding.

As we started to double code and compare codings of items, I was wondering if it's possible to add a function (like a checkbox on the top of the form) that will allow us to indicate which coding should be treated as the primary or final decision?

Thanks!
Hsiaolin

From Hsiaolin's email:

As for the actual coding page/functionality, we would like to do double coding—2 coders each code the same items independently, then compare and negotiate to establish the final coding—on the platform directly. To do so, we would like to be able to:
...
• compare two codings and highlight differences for further negotiation;
• create a third form (that includes the final coding decisions), or mark an existing form (with some notes next to changes) as the final form.

This is mainly a UI issue, I think.

The coding scheme now defaults to Wang, which is cool, but manually setting the coding scheme to the "undefined" option (--------), for whatever reason, leads to a Django error page when the item is saved, with the following unhelpful message:

No such file or directory: '[SATI_ROOT]/sati/items/schemas/.json'

Probably this field should be set to required so that attempting to use the "undefined" option generates an in-band This field is required. message, as happens with most other input fields.

This would be nice to have, perhaps a sidecar Tesseract container could be used? (Probably on a cron-ed basis, rather than on a trigger of any kind.)

In addition, we would also like some filter settings or some kind of “assign” function to help our coders to find and work on the same new items with ease.

I think filter (and probably a column) for "has codings" and another (without a list column) for "coded by" probably takes care of at least 80% of this.

The system keeps prompting and requiring us to specify "Test" on the item page.

This is currently allowed. It's not obvious why one would want to do this via the interface; not choosing an attribute is more likely to be a mistake that perhaps should be flagged via an in-band error message noting that at least one attribute must be selected.

In the case of bulk uploads, though, there probably could be a scenario in which a coding is created but not filled in, with the intention that someone would fill it in later via the interface. But in that (hypothetical) case, the initial coding creation wouldn't be done via the interface, so this question wouldn't really apply.

To reproduce: create an item, add a coding, save the item, browse to the item's codings, try to expand a coding (to view or edit it) by clicking on the arrow or the label (e.g., Coding: Coding by [email protected], 2021-01-14).

It seems as though the click event isn't triggering the intended style change to expand the coding display element.

This has only been tested/reproduced with dummy test items created from scratch via the interface. Not sure if it would happen with codings added to items created via bulk update.

Stacked or tabular inlines are cumbersome in this context -- can we use tabs or a similar mechanism to make these a little less unwieldy? Perhaps this becomes easier if #8 is implemented?

      - name: Set up Python 3.8
        uses: actions/setup-python@v2
        with:
          python-version: 3.8

This results in the the latest patch release for 3.8 being used (3.8.x) as seems reasonable. However, if a cached .venv created with a different patch version is restored, the build fails (not sure if this might be considered a pipenv bug?).

In any event, two options present themselves:

1. Pin the patch version of Python (for the Actions runner, if not necessarily for the project as a whole).
2. Tag the cache with the major.minor.patch version of python it was built with, and invalidate as appropriate.

The logged in user and creation/modification time need to be saved at least, perhaps more.

These ones:

The JSON dumps in sati-data could be cleaner -- e.g. the codings could be reformatted to prevent so much bloat (without sacrificing readable diffs), and/or is there a way to dump the individual models to JSON files instead of the entire app?

It's currently showing : 4.2.2B Discrete: numeric, but should be corrected to 4.2.2B: Discrete: Textual.

Thanks!

We might include items from biology, chemistry, and others, so it's necessary to have the function to add new content areas. Thanks!

This makes migrations and working making adjustments to the "live" database a whole lot safer and easier to manage.