Inconsistent Capitalization on Copy of Size in Properties Screen

in utopian-io •  7 years ago  (edited)

Expected behavior

The first 'S' in 'Size of folder copied to clipboard' should be capitalized to be consistent with the capitalization of the first letter in the messages for copying other attributes (e.g. Name, Location, etc.)

Actual behavior

The first 's' in 'size of folder copied to clipboard' is lower case. This is inconsistent with the messages which display when copying all other file attributes because all of their messages start with a capitalized letter.

How to reproduce

  1. Launch Amaze File Manager 3.2.1 on Android 7.1
  2. Click the 3 Horizontal Lines icon in the upper left
  3. Select 'Recent Files'
  4. Click the 3 Vertical Dots icon to the right of a File
  5. Select 'Properties'
  6. Tap-and-Hold on 'Size'

Device: Nexus 6P (angler)
OS: LineageOS 14.1 (Android 7.1.2)
App Version: 3.2.1

Recording Of The Bug

gifeditor_20180115_115710.gif



Posted on Utopian.io - Rewarding Open Source Contributors

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

Your contribution cannot be approved because it does not follow the Utopian Rules.
Welcome to utopian and thanks for contributing
But i regret to inform you that, this is a developer intended Feature. if he wants the s in Size as a lowercase he can add it. this is not a layout bug.
If you want the s to be an upper case. kindly post in Suggestion. we only accept quality bugs which actually affects the functionality of the app.

You can contact us on Discord.
[utopian-moderator]

@sachincool Inconsistencies in capitalization in the same types of messages are most certainly considered bugs. All other messages of this same type on the same screen are capitalized. This is clearly an unintended error.

please read our rules, we have clearly mentioned unintended crashes or layout issues are considered as bugs. infront of them the s and S comparison cannot be consider as a bug. We reward quality and posts which follow our rules. if you want the s to be a S that is your opinion. and no other user suffers from a lack of functionality lack in this case the functionality works perfectly fine and that is our target here. i hope i am clear
thanks for understanding.

Other bugs you've approved from me don't fall under the definition of crash or layout issues, so I think there needs to be a rewriting of your definition of a bug. It is currently unclear. I volunteer to help with that if it is desired.

In my 7 years QA Lead experience at Microsoft an inconsistent capitalization of the same type of message on the same screen is definitely a bug that the developer would want reported. It looks unprofessional and is obviously a bug even to a User. I think it would be sad if Utopian-IO started making those types of decisions for the developer causing them never even learn about a bug they'd want to fix because a moderator considered it minor.

I believe a moderator should decide whether it is a bug, and let developers decide whether it is too minor to fix.

Where should I go to discuss the larger scale question of how bugs are defined in the Utopian community?

Side note, I just searched all of the rules, and I see no reference to only crashes and layout issues being considered the only valid bugs. Is that in a private moderator version of the rules perhaps?

You may contact my Supervisor :)
P.s thanks for stating your background, i see you are indeed of high caliber. i think i should state one thing

Suggestions are also posted on github as an issue. But without the "bug" tag. we Utopian made it like that so to help, with some user specified changes or requirements or the Application which doesnt actually have an impact on the functionality and the developer can focus more time on some high priority bugs or crashes. I never said to forget and give up on your s or S bug, i only stated to make it under suggestions. As Utopian we want QUALITY QUALITY QUALITY. That's our Motto. I think you misunderstood my stance on your bug. I didn't see the critical level of that bug up to the mark to be posted as an Instant emergency for the developer to see or check.
that change is so small, it should be posted as an Hacktoberfest label for the new kids and students joining the open-source :). Don't you think so?

Thanks for your help @sachincool! I'll check in with @knowledges and try to figure out a way to distinguish more clearly between bugs and suggestions for future submissions. I think this will be helpful to the community moving forward.