Re: [H-source-users] Introduction

[bill-auger]

On Sun, 18 Jul 2021 11:48:50 -0400 Bone wrote:
> Yes it eliminates the need to store user passwords.

it eliminates an automated mechanism, which entails nearly zero
workload to maintain; and replaces it with a significant manual
workload (cleaning the trash)

IIRC, we discussed allowing anonymous contributions via the
h-client; but it did not seem to be worth the effort - a second
idea was to hard-code a distro-specific login - that is
effectively anonymous; but would allow certain clients to be
blocked, if users of one particular distro were abusing it,
without blocking all anonymous uploads


On Sun, 18 Jul 2021 11:48:50 -0400 Bone wrote:
> > Although it raises the barrier for contribution,  
> 
> The use of Git could be a barrier to people that want to contribute to
> h-node and are not familiar with Git.  To help mitigate this a detailed
> tutorial teaching how to make h-node contributions using Git could be
> provided.

the choice of back-end should be irrelevant to the user - that is
a general rule for any client-server system; because it is a good
engineering practice to isolate components, which do not need to
know the internals of each other - the same general rule is a
corner-stone of OOP, for example - this suggestion requires each
user to have total knowledge of the data-model schema, and
additional management to monitor their every move, to ensure
quality - from an engineering perspective, it is a return to the
1950s, when the only people who ever touched a computer were
highly-skilled and rigorously managed, and computer time was much
more expensive than the time of technicians and managers

regardless of the back-end, it is not very desirable to have
users filling data fields directly - that is the most likely
route for invalid data to enter the system - it is the very
reason why the h-client was written - anyone who wants to add
their hardware data, should not need to use the website or git,
only the h-client - that is the best way to ensure the quality
of the data, and is much simpler to use, for anyone, with no
technical skills


On Sun, 18 Jul 2021 11:48:50 -0400 Bone wrote:
> h-node already has the significant (necessary) barrier to contributing
> of requiring a FSDG operating system or Debian installed.

to be clear about that, the data is most relevant to users of
linux-libre or the debian kernel - those kernels can be used
with any distro - gentoo for example, has a libre-only option,
just the same as debian


On Sun, 18 Jul 2021 11:48:50 -0400 Bone wrote:
> > and also means someone has to review all changes and merge them into
> > the main site every time.   
> 
> One of the advantages is that it adds a quality control check on
> submissions before they are include in h-node.

to be clear it does not "add" quality control, it requires a new
manual chore, which is currently not necessary

the h-client already ensures the quality of the data to a high
degree, and is a much simpler tool to use - if no one is
moderating submissions now, and there has not been a spam
problem yet, then keeping the h-client as the preferred upload
interface, is the obvious best option

again, the back-end should not be relevant to the user -
h-client could be modified to be a git client, or anything else
- but if the back-end is irrelevant to the user (as it should
be), then it makes the most sense to keep as much of the existing
back-end as possible, if UX is the only concern that a new
back-end intended to address

in short, if the goal is to make contributing to h-node more
user-friendly and accessible, the best and easiest path is to
focus on the client - ensure that it is screen-reader/braille
compatible, ensure that it functions fully on a CLI system, etc
- that would be very easy to accomplish, compared to the total
re-writes being proposed - there may be merits to re-writing the
back-end; but user-facing concerns are not among them