Are new users subjected to prejudicial or intensified scrutiny by reviewers?

Question

I have an experience to share as a new contributor to unix.stackexchange.com where I sensed some slight undercurrents of prejudice.  It would be great to receive a response from the users mentioned here but any input, technical or otherwise, from others is welcome.  I was not able to respond in situ with my thoughts so pardon me for creating a new question.

Observation 1: New contributors cannot comment on their own posts [Resolved]
I attempted to contact a contributor via a minor edit to muru's lowest rated answer to question 278443 regarding the "mangled code", where he responded "you can always address editors to your post by commenting with @username".  I couldn't comment, only edit, my posts.  The resultant URL after clicking "comment" was: What's the POSIX way to read an exact number of bytes from a file? where the query is noredirect=1#.

Observation 2: A possibly valid edit by a new user is ignored
Incidentally, I found a possible error in muru's answer to question 278443 where he said that the command dd bs=1 count=1000000 "will be horrendously slow".  This involved processing only 1 million bytes which would not be slow.  A test on my dual-core took 1.8 seconds.

$dd if=/dev/urandom of=~/tmp1 ibs=1 count=1000000
1000000+0 records in
1953+1 records out
1000000 bytes transferred in 1.844224 secs (542233 bytes/sec)

With bs=1 for large amounts such as 1TB then, yes, it would be much slower in comparison to bs=64M, which is probably what he had in mind.  Though I believe my reasoning was sound my edit request was rejected.

Observation 3: Logical reasoning is not always required by high-rep users, only statements
In my first draft of the edit to muru's answer I realised that I had altered it too much and decided to post my own answer to question 278443.  I said "a partial read by dd with ibs=1 would be unlikely".  A high-rep user Stephen Kitt commented that "it is impossible".  That comment has since been deleted but how is it impossible?  For raw data without a multiple of 8 bits i.e. 0< n mod 8 <8  and ibs=1 where the block size is 1 byte or 8 bits how does dd deal with a read of, say, 3 bits?  I do not know, particularly with older media such as tape and older versions of dd.  My knowledge on dd is limited here.  If Stephen Kitt had the time to explain or point to a relevant post on this topic then this would fill in the gaps.  I have not yet found any further information to support his statement.

Observation 4: Plausible solutions by new users are disparaged
Question 278443 is "What's the POSIX way to read an exact number of bytes from a file?".  I then added an option using the read command, stating that there are limitations after testing a few successful examples.  I received a comment recently from Stephen Kitt saying "POSIX read is very limited, so in the context of this question, your read approach doesn’t work".  "Limited" and "doesn't work" are mutually exclusive mathematical probabilities.  In the context of the question, read is a built-in command of POSIX that can be successfully used to read an exact number of bytes as long as certain conditions are met.  There are limitations, as stated in my answer, but the OP did not require a failsafe or limitless option.  Even so, if Stephen Kitt can briefly explain these limitations then I can understand why my answer doesn't work.

Observation 5: Self-deletion of a post by a new user is not possible [Resolved]
Seeing that my answer, described in Observation 4, was not beneficial I then attempted to delete it by clicking on the "delete" button at the bottom of the post: "share", "edit", "delete", "flag".  However, I was not able to do so.  The result is a client-side redirection to What's the POSIX way to read an exact number of bytes from a file? where the query is noredirect=1#, which only goes to the top of the page.

Observation 6: Prejudice favouring long-standing users
I noted that muru's post on the same question (278443) possessed similar, if not, less merit than my answer, yet apparently received no critique from reviewers.  His post had a score of "-1" prior to my posted answer and "0" afterwards which indicates to me that it was probably upvoted by Stephen Kitt.  

Observation 7: High-rep users can edit and approve at will, even if incorrect
A few days ago I posted an answer to a Vim question at unix.stackexchange.com and a high-rep user muru edited it in kind, but inadvertently introduced errors into the code.  It was a by-product of format conversion and I rectified it, but it appeared muru's edit wasn't reviewed by a third party because of certain privileges/status because the error was not noticed.

Discussion
As I have only spent a few days on the unix.stackexchange.com site it is too early to make conclusions.  I don't believe the aforementioned contributors are making any begrudging or personal attacks but I am of the impression that there is a hierarchical culture where there is bias between new and long-standing members.  I understand that moderators will need to politicise their responses, but is this true?  Is there a pecking order here or is this community on a level field of information sharing?

My system (05-Nov-2020):

• iMac 2006, Mac OS X 10.6.8.
• Chrome 49.0.2623.112 (64-bit) (unsupported). Chrome settings: Javascript enabled, Images enabled, Cookies enabled.
• I can navigate to https://googleapis.github.io/ and http://sstatic.net/ pages.

Answer 1

First of all, thank you for coming here to Meta with a polite, calm question as you have done. I know how confusing the rules can be to new users, and it is always appreciated when people ask instead of ranting.

Next, I want to point out that none of the users you mention are moderators. Moderators are elected by the community and have a ♦ after their names. You can see the list of moderators here: https://unix.stackexchange.com/users?tab=moderators

The people you mention are high-rep users. This means they have enough reputation to be able to perform certain actions on the site. For more on the various reputation thresholds, please see https://unix.stackexchange.com/help/privileges.

On to your observations!

Observation 1: New contributors cannot comment on their own posts

New users can comment on their posts. They can't comment on other people's posts (you need 50 rep for that, which is essential to block spammers from commenting). If you really couldn't comment on your post, then that's a bug. Could you please try again and confirm it so we can report it?

Observation 2: A possibly valid edit by a new user is ignored

Your edit can be seen here: https://unix.stackexchange.com/review/suggested-edits/356718. You are removing the "horrendously slow" but you don't actually give any arguments to support it. Also, the message you used to explain the edit was your attempt to contact Muru. So Muru probably thought the whole edit was only to contact him (you need a minimum number of changes to suggest an edit, so he may have thought you just removed the phrase only to get the edit through). If you really feel that "horrendously slow" is worth editing out, you can try submitting a new edit but this time give your reasons for removing it so that the post's author can understand.

Observation 3: Logical reasoning is not required by moderators, only statements

I don't really understand the problem here. First, as I said in the beginning, the user who commented is not a moderator. Second, if a comment has been deleted, why are we still discussing it? Perhaps the author of the comment made a mistake, realized it and then deleted it. In any case, comments are free, you can say what you want in them (you shouldn't, ideally you should only comment about the question, but you're free to write what you like).

In any case, I can see a comment there now:

POSIX read is very limited, so in the context of this question, your read approach doesn’t work :-/. – Stephen Kitt

The comment is explaining that the POSIX implementation of read is limited. Specifically, I assume Stephen meant that POSIX read doesn't support -d or -n, but only -r. This means that your answer won't work with POSIX read. Yes, Stephen could have made that a little bit clearer, but next time just answer the comment and ask for clarifications (always assuming there's no bug that stops you from commenting on your own posts).

In all, I just don't see any problem here nor any reason to think this has something to do with your being a new user. I've been a user for several years now, I'm in the top 10 users by reputation and an elected mod and I still get comments pointing out errors in my answers. This is a good thing!

Observation 4: Plausible solutions by new users are disparaged

This seems to be the same as the point above. As explained, your answer doesn't work for POSIX read since it doesn't support the -n or -d options, and the question was asking specifically about POSIX read. Therefore, your answer doesn't work for the question. Again, this has nothing to do with your being a new user. Also, the only thing that happened is that a helpful user explained what the problem was. I don't understand what made you feel your answer was "disparaged". There's no disparagement here, only a polite comment pointing out a problem.

Observation 5: Self-deletion of a post by a new user is not possible

You can delete your own answer unless it has been accepted. Just click on the "delete" button under the post:

Again, if you couldn't, there's a bug so please try again and let us know. Make sure you are using the same account to log in. Could you perhaps have tried to delete it when not logged in?

Observation 6: Prejudice to moderators and long-standing users

Once again, no mods were involved. And Muru's post doesn't use read -n so it doesn't have the issue that Stephen helpfully pointed out about your answer. Why, then, should that answer have the same critique? As for who voted, you have no way of knowing that (not even moderators have access to voting data), so I would urge you not to make assumptions.

But no matter who voted, people are free to vote as they like. Nobody has voted on your post (although I would understand it if they had downvoted since one of the solutions you offer doesn't work with POSIX read). Two people have voted on Muru's answer, one person found it good and upvoted and one found it bad and downvoted. So if anything, it is Muru, an established, high-rep user who is facing "prejudice" since it is he who got a downvote. Now I don't think that's prejudice at all, I am just pointing out that he's the only one who got a downvote, not you.

Finally, the SE sites try to be egalitarian. However, because there is the rep system, it is indeed true that sometimes people with more rep are listened to more. This isn't encouraged, and shouldn't be the case, but we're all humans so some people do react differently to high rep users. I'm afraid nobody can do anything about that though since it is down to how each individual reacts. Reputation on this site is supposed to represent the level of trust the community places in a user. Therefore, the more rep you have, the more trusted you are and the more trusted you are the more weight your statements may have for some people. This is just human nature though and is not under any circumstances the official stance of the community or the moderator team.

In theory, every user is supposed to be treated equally. In practice, this sometimes does fail but when it does, if you feel someone is being rude or dismissive of you because you're new, please flag the rudeness or come here and open a discussion on Meta. No system is perfect, and having reputation can indeed breed a feeling of elitism, but we do try and avoid that.

Answer 2

terdon has already addressed most of your points, but your question includes some issues that I think only I can address.

First, I’m not a moderator, and even though I have a lot of fake Internet points, I don’t have all that many special powers as a result.

Second, it is quite possible that new users are subjected to more scrutiny than others, because their posts show up for review in the first posts review queue or in the late answers review queue; you can see my review from the latter here. I actually hadn’t realised until just now that the late answers queue only includes new users’ answers! My review wasn’t related to your being new; it was related to your answer being a late answer. I expect these to add relevant information which isn’t present in existing answers; I commented as such on your answer, since the ibs=1 approach had already been described elsewhere, but I didn’t take further action (e.g. suggesting that your answer should be deleted).

Observation 3

I tend to assume that people interested in a question have read all the surrounding material (in the question, comments, answers, and linked questions), which is perhaps unfair. The impossibility of partial reads when the input block size is 1, as far as dd is concerned at least, is explained in this answer:

This suggests a solution: use an input block size of 1. No matter how the input is produced, there's no way for dd to read a partial block if the input block size is 1. (This is not completely obvious: dd could read a block of size 0 if it's interrupted by a signal — but if it's interrupted by a signal, the read system call returns -1. A read returning 0 is only possible if the file is opened in non-blocking mode, and in that case a read had better not be considered to have been performed at all. In blocking mode, read only returns 0 at the end of the file.)

Observation 4

When I wrote “POSIX read is very limited”, I was only saying that: read, as defined by POSIX, doesn’t have much in the way of options, and is pretty much limited to handling newline-delimited input as full lines. As a result of that, “in the context of your question, your read approach doesn’t work”. The two statements don’t qualify the same thing: the first qualifies POSIX read, the second qualifies your use of read. Because the question specifies POSIX only, you can’t use extensions to read as implemented in Bash for example.

In the context of the question, read is a built-in command of POSIX that can be successfully used to read an exact number of bytes as long as certain conditions are met.

As far as POSIX is concerned, read is a utility (traditionally a shell built-in, but the specification doesn’t require that), and as defined by POSIX it can’t be used to read an exact number of bytes.

Observation 6

I don’t know who upvoted muru’s answer, but it wasn’t me. If there’s one thing to always bear in mind regarding votes, it’s that you can never assume anything about them.

Here’s proof:

Neither of the arrows are highlighted, which means I haven’t voted either way.