On Fri, 2022-11-18 at 08:05 +0000, Tony Abbey wrote:
>
> That's a hell of a rant Gerhard, but doesn't answer how a user like myself
> can actually help. [ ... ]
> Can you give me a link to the steps needed to review/approve new code?
> I'm sure many of us would like to help if we knew how, otherwise its just a
> request for features and reports on bugs which you call 'gimmes' - very
> unhelpful!
OK, I gave it a few more days to see if anybody else could say
something helpful. Seems to not be the case. Isn't _that_
telling? And is it not terribly sad? I'm still not at all
"getting" this silence on so generic a subject as reviews are.
Nobody familiar with the concept? Or not interested in helping?
Again this waiting for a developer to do it? That's how you lose
them. (Must assume that those who know this stuff and _could_
speak are just as exhausted as sigrok core developers are. Any
other explanation would be worse, I'd rather assume a positive
one.)
Do you honestly need me to tell you how to review something? Need
I really explain? Are you waiting for a formal procedure, or a
form to fill in? Or what's the actual question that you expect "a
developer" to answer? Common sense would have helped here, or
should have. Or a talk to any software developer with some
experience, need not be a sigrok guru at all. (If somebody
creates software and doesn't know how to review something, then
that'd be the difference between a programmer/"coder" and a
software engineer.)
Here is the secret how I perceive it. It's rather simple: You
learn about a submission's existence. You go to the place where
it's published. You look at the information that is available
there. You combine it with other information and knowledge that
you got. You consider what you've seen, then you talk about what
you thought when you have seen what you were looking at. There
really isn't much to it, just needs to be done. Try it.
Is this not also how you form an opinion in other situations of
your life? You look, you think, you speak. Ideally in that very
sequence. Iterations are strongly recommended to improve the
result. Learn something from talking to others. Take another look
after you have learned and improved. Think again after you have
seen more after you have learned more. Talk how you see things
differently or in more detail after you have thought some more
after you took another look. Do several of these iterations.
It's universally applicable.
So if the above sequence of look-think-speak is obvious, then why
"need" I explain? Which part of it was surprising, or uncertain?
Go and attempt to review that very submission which Paul kept
asking for feedback about. I'd suggest that Paul also tries to
view and review the submission. Some time has passed, you
probably have improved since then. Would you still address that
subject in the same manner? Forget that it was you who wrote it,
try to see it as if you were the recipient. You are not making a
gift, you are requesting somebody else to accept your submission
into their code base. Consider that. Seriously. Must be a match,
and should be of a minimum quality, to be acceptable.
If you think that "a review" would be the process of "pressing
the accept button" or "voting" or "vouching" or another form of
"talking a developer into taking anything regardless of state"
then I cannot help. I'm not familiar with these concepts in the
context of software development. And don't want to apply them to
the sigrok code base. You expect the software to work, I expect
it to remain readable and maintainable. So do the maintainers who
gave me the commit bit.
As I said before: Merging commits and pushing them is the trivial
part. The smarts is in reviewing submissions, and improving them
to make them acceptable before they can get merged. And that's
something which does not take any commit access at all, neither a
title nor a specific role or anything. And I've said it before: I
expect users to help there. Most review feedback would be generic
about software development (code hygiene), language use
(programming as well as natural), version control habits. Few
are specific to sigrok itself, its API or internals, and require
a core developer's attention.
And let me repeat: The current lack of reviewers is a consequence
of the community not having raised them in the past. The fact
that the project currently has so few active people, and
essentially no candidates to extend the core, is neither a
necessity nor a coincidence. It was made. By watching, relying on
"a developer will do it eventually" and "users cannot help, they
must wait, and watch". Keep saying that a few more times, to
yourself or in public it doesn't matter, and there will be no
developers left at all who can do that work for you. If you are
unsatisfied with the current state, then consider doing something
helpful. Support your fellow users when they ask for help, don't
wait for a developer to do it, all of it, and every time, while
everbody else watches. Support developers if they ask for help,
don't watch and wait for them to "somehow manage" while they
scream at the top of their lunges and sincerely request your
help. You only got a few developers left, don't waste them.
virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
