I think MobileFrontend's "more than 5 edits" logic needs to be investigated. It appears to currently be a hardcoded value that's completely separate from autoconfirmed.
We should figure out whether autoconfirmed logic or similar can be re-used here. At the same time, we can also re-examine the underlying use-cases for deploying this logic altogether.
I'm ok with using the autoconfirmed group. The only reason for the "5 edits limit" is to ensure, that a user has done some things on the website and so we can assume, that he will not be shocked and runs crying away, if there are some more options on the UI. Remember, that autoconfirmed relys on more then only the edit count, alos the "age" of the account. And the edit count is higher then 5 on most wikis (or mostyl 4 days, if the edit count is 0), at least on wmf wikis.
Like I said: I don't really care, what option to use (as far as it fulfills the requirement I explained above), and if the community is ok with the autoconfirmed group: let's do it! :)
With regards to the phrase:
It wouldn't be a problem to add the link only, if the user is logged in and has more than 5 edits (like the talk button).
I'd suggest that if a user is logged in, then they should be given access to all the available features regardless of whether they've had five edits/are autoconfirmed etc. IMO being logged in is a sign that you're wanting 'full access' (whatever that means).
@Wittylama sure I had fought this originally, but given the conversation here: T118338, I think that's probably a better proxy for 'interest'.
Curious though--is this because anyone is complaining, because the principle is more sound, or because it's duping logic elsewhere.
I'm not quite sure what about that other thread confirms the idea that 5-edit is the best method of guessing 'interest'.
No one is complaining specifically about "5 edit logic" as far as I'm aware, rather, they're annoyed at the lack of tools/options that would normally be standard features when editing. [and, even when just reading - like why are the navboxes at the bottom of articles hidden on mobile??]. So, I think the issue is best described as "inventing a new solution to an already solved problem" (I assume that's what you mean by "duping logic"?). Either "logged in" or "autoconfirmed" are pre-existing states in the software that indicate interest. I just don't know why you need to introduce a new measure for this.
The "suggested articles" feature (when manually edited) seems to be another case of "inventing a new solution to an already solved problem"...
I'm not quite sure what about that other thread confirms the idea that 5-edit is the best method of guessing 'interest'.
This is a misunderstanding and I apologize for the unclear wording. I was saying that I originally fought the 'logged in' logic, but the conversation alluded to showed that the logged in logic was probably better (or at least had more support).
Thanks for explaining the concern further.
I agree with you about 'suggested articles'. I like the idea of keeping them algorithmically derived (like search results), but we built-in editing as a possibility because we wanted to honor editor intentions. I think I described the value, regardless, here: https://www.mediawiki.org/w/index.php?title=Topic:Suqj6do13qpmlerd&topic_showPostId=suqvqozn6kz0pzmu#flow-post-suqvqozn6kz0pzmu
So it seems the action is that we change talk to show to all autoconfirmed users and use the permissioning system in core rather than create our own logic?
If no objections let's make this happen.
Please let's not derail this conversation with talk about suggested articles - please continue those conversations on wiki.
works for me, but if @Wittylama feels strongly about logged in v. logged
out then that works too.
My only position on this issue would be not to "reinvent the wheel'. I prefer if you choose "logged in" rather than "autoconfirmed" as the measurement of whether someone is sufficiently "interested" to warrant showing them more features - because it is the lower bar for entry and is also a feature that is a standard binary option across all wikis (whereas the level at which autoconfirmed is set can be adjusted on a per-wiki basis [I think]).
However, I would nevertheless like to note my feeling that I don't think the "talk" link SHOULD be hidden in the first place. It should be available to be seen by all people in all circumstances - it's a core component of the way Wikipedia works, not a an extra feature on the side. The fact that talkpages are an ugly mess (especially) is a problem that should be dealt with by Flow, rather than hiding them.
My only position on this issue would be not to "reinvent the wheel'. I prefer if you choose "logged in" rather than "autoconfirmed" as the measurement of whether someone is sufficiently "interested" to warrant showing them more features - because it is the lower bar for entry and is also a feature that is a standard binary option across all wikis (whereas the level at which autoconfirmed is set can be adjusted on a per-wiki basis [I think]).
Sounds fine to me. I created a ticket (T122311) to this effect and added it to our backlog. I will be off for a month starting today, so the temporary product owner, @dr0ptp4kt will prioritize it as he sees fit.
However, I would nevertheless like to note my feeling that I don't think the "talk" link SHOULD be hidden in the first place. It should be available to be seen by all people in all circumstances - it's a core component of the way Wikipedia works, not a an extra feature on the side. The fact that talkpages are an ugly mess (especially) is a problem that should be dealt with by Flow, rather than hiding them.
I agree that this would be the best way to handle the issue. There is a collaboration team working on flow/talk pages and they can effect change there. All I can do is let them know it only shows to logged-in users until it's better and you can put pressure on them to make it better (or on communities to adopt flow).