muctadir / lama Goto Github PK

In general, when there is no content to display, it is better to show a message explaining this and possibly some additional action for the user to help avoid confusion or an impression that content is failing to load.

Examples:

• When there are no projects, you could include a message like "No projects available" and an inline button to create a new project
• When adding users to a project and none are available, you could include a message like "you're the only user" and an option to invite new users (ie, by email)

Submitted while reviewing openjournals/joss-reviews#5135

In many areas of the application's layout, it is set such that the contents of the page will go as wide as the page width. particularly when dealing with, say, an ultrawide monitor, this makes it difficult to follow the contents of the page as it hurts things like visual grouping of fields and action buttons and generally hurts the ability to scan the content of the page (having to find small pieces of content in widely separated parts of the screen, reading very short content in very wide fields, text going wider than ~70-80 characters, etc). In many cases, there should likely be maximum widths added either to the entire page layout or specific components of the page (eg, even if you cap the width of all pages, the username and email fields on the account creation screen should be much shorter)

Submitted while reviewing openjournals/joss-reviews#5135

The docker setup is very straight forward (kudos!) but there doesn't seem to be clear documentation beyond software requirements for getting set up for development (what commands am I expected to run? how can I run things with hot reloading? etc).

Related: Following the instructions provided in the README is not sufficient for running tests successfully. You need to install the python requirements via pip to run the backend tests, and even after installing the frontend requirements via npm and setting my chrome binary, no tests were found.

Submitted while reviewing openjournals/joss-reviews#5135

It would probably be more intuitive to have more consistency in the navigation structure. Namely:

• Including a homepage link and account settings on all pages, including while in a project, when editing a project, etc
• Removing the homepage and log out links from the secondary "project" nav (or otherwise have a clearer delineation between navigation items that are specific to the project vs site-wide)
• Instead of redirecting the tagging and conflict pages back to the stats page when not available, either 1) having a page with an empty state (maybe with some indicator of if/how many entries are available to act on, like an inbox) 2) removing them from the sidebar in favor of making them ephemeral pages entered into from the homepage or 3) only show them when there are items available to act on, and visually distinguish them from other nav items (eg changing color, background, etc) so that it's clear they're "exceptional" (reducing confusion around when they are/aren't there and making it clear that something not normally there is now there)

Submitted while reviewing openjournals/joss-reviews#5135

Currently when going to your account settings, you get a view-only mode and have to additionally click an edit button. Is this necessary? Most sites I'm aware of directly send you to an editable page.

Submitted while reviewing openjournals/joss-reviews#5135

Currently I'm a little confused about the scope of what is being submitted to JOSS within the context of the previous versions of the application. Namely:

• Is the submission considering this version and the prior two versions as the scope of the contribution?
  • If so, it doesn't look like all prior contributors are included as coauthors, which may suggest a need for revision
  • If not, what is distinct about this version beyond the prior versions? What exactly is the scope of the work done here? What issues or imitations in prior versions were addressed? What is new in this version vs prior versions?

This may warrant some clarification in the paper itself, though I'm not sure if that's necessary (maybe worth checking with the editor?)

Submitted while reviewing openjournals/joss-reviews#5135

Hi,

Part of openjournals/joss-reviews#5135, I checked out the code, and noticed a package-lock.json in the source directory. I think that file is normally generated from a package.json, and, normally, is stored in the same directory as that file.

Is there a reason for having that file in the root source directory, instead of, having that only in the frontend directory?

Cheers,
-Bruno

Hi,

Related to openjournals/joss-reviews#5135; the Linux command in the README.md file doesn't work when pasted in the command-line. I've submitted a quick PR for that, see #8

However, running the command I get:

Please run with privilege

Looking at the sources, it runs docker-compose --env-file .env -f Docker/docker-compose.yml up --build -d.

If I modify the command, and use docker compose instead, that runs fine on my computer without the need of root access (I did that step to run it rootless).

The script also appears to have some logic to ask the user the operating system,

echo "What operating system are you running?"
echo "1) Windows"
echo "2) Linux"
read -p 'Boot option: ' os
if [[ $os != 2 ]]
then 
    echo "You gave an invalid option for the OS (either not 1/2 or Windows)."
    echo "Try again by reopening the file. Goodbye for now!"
    exit
fi

That doesn't look useful as there are two scripts, one of Linux and one for Windows. There could also be MacOS users that could not be sure which version to choose.

IMHO, it'd be easier to just list the docker compose command, and leave the operating system out. Or re-write the installation process to simplify it, and make sure the docs work for users on Linux and/or the possible issues & variations of commands are documented (e.g. maybe say "if you have docker compose, you can run this command... if you have not configured it as rootless you may need to use sudo, etc..").

Cheers
-Bruno

I imagine in many installations, admins would want to only allow specific individuals to create accounts. It should probably be possible to turn off public account creation in favor of just sending email invites to provision new accounts.

Submitted while reviewing openjournals/joss-reviews#5135

There are a number of instances where buttons don't look clickable (eg the add members and create label buttons), as well as text that looks like links but are not (eg the project stats and user stats headers)

Submitted while reviewing openjournals/joss-reviews#5135

There are a number of instances where obscure errors are presented to the user where it is unclear what the issue was and how the user could correct it. EG:

• When creating a new label with missing fields, an error is just shown saying "invalid input"
• When creating a new account without a description (why would I want to add a description for my own account when creating it?) a 500 error is seen
• When creating a new account with a weak password, just "invalid password" is shown

Related: It should be made clear when fields are required when it isn't obvious, and if a particular format is required (eg specific password validation rules) that should be given up front.

Additionally, errors should ideally be shown directly next to fields they're related to, if applicable

Submitted while reviewing openjournals/joss-reviews#5135

Hi,

I am reviewing your JOSS paper 👋 openjournals/joss-reviews#5135

JOSS has a list of requirements for the paper. This issue is about this one:

Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

It's common for projects hosted at GitHub to contain a CONTRIBUTING.md file, e.g. https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors

Your repository doesn't seem to contain that file, and the README is also missing that. Maybe that file could contain the instructions for running & test docs, or the README file could be extended...

Note that the README has a Contributions entry that's confusing too, in the table of contents. Maybe that could be renamed to Acknowledgements, to match the title used.

Cheers,
-Bruno

Hi,

Related to openjournals/joss-reviews#5135, the item

Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?

Looks like GH Actions is only building the PDF at the moment? Any plans to add tests to the frontend and to the backend, and run them automatically on GH Actions?

Hi,

Part of openjournals/joss-reviews#5135. I see you mentioned commercial tools in the statement of need of the JOSS paper. The first item in your list of trade offs is the cost. However, that statement of need seems to ignore the existence of other OSS tools that could be compared to LaMa.

Could you consider adding other OSS tools, please? For example:

• https://web.hypothes.is/
• https://github.com/dataqa/nlp-labelling
• https://github.com/heartexlabs/awesome-data-labeling#text
• https://github.com/topics/data-labeling
• https://github.com/topics/text-labeling
• ...

Cheers,
-Bruno