Migrated from "label: enhancement" to "Type: feature" (#59)

* Migrated from enhancement to feature

* Migrated from enhancement to feature

* Fix: minor changes

* Fix: minor changes

* Fix: Migrate from enhancement to  feature

Author: Kota-Jagadeesh

android/Code-style.md

@@ -34,11 +34,11 @@ In short, please discuss things with us before you submit a PR with a new librar
 
 ## Architecture
 
-Please follow the [MVP architecture](https://github.com/commons-app/apps-android-commons/issues/888) if you are submitting a large enhancement (definitions of "large" vary according to context - if you are not sure whether this is needed for your code, ask beforehand)
+Please follow the [MVP architecture](https://github.com/commons-app/apps-android-commons/issues/888) if you are submitting a large feature (definitions of "large" vary according to context - if you are not sure whether this is needed for your code, ask beforehand)
 
 ## Unit tests
 
-Please write unit tests to cover your own code if you are submitting an enhancement (i.e. the issue that you are working on has an "enhancement" label)
+Please write unit tests to cover your own code if you are submitting a feature (i.e. the issue that you are working on has a "Feature" type)
 
 ## Logging
 

android/Contributing-Guidelines.md

@@ -10,8 +10,8 @@ You **must**:
 - Add Javadocs to all new methods and classes that you create
 - Follow correct procedures if adding a new library (additions of new libraries must always be discussed and approved beforehand)
 - Escape HTML tags in strings
-- Write unit tests to cover your own code if you are submitting an enhancement (the issue that you are working on has an "enhancement" label)
-- Follow the [MVP architecture](https://github.com/commons-app/apps-android-commons/issues/888) if you are submitting a large enhancement (definitions of "large" vary according to context - if you are not sure whether this is needed for your code, ask beforehand)
+- Write unit tests to cover your own code if you are submitting a feature (the issue that you are working on has a "Feature" type)
+- Follow the [MVP architecture](https://github.com/commons-app/apps-android-commons/issues/888) if you are submitting a large feature (definitions of "large" vary according to context - if you are not sure whether this is needed for your code, ask beforehand)
 
 You should also:
 - Follow the [Google Java Style Guide](https://google.github.io/styleguide/javaguide.html)
@@ -102,7 +102,7 @@ format, or this invocation of "git show":
 Read the importance of commit message in the [linked blog](https://blog.oozou.com/commit-messages-matter-60309983c227?gi=c550a10d0f67).
 ### Write tests for your code (if possible)
 
-When adding a new feature or submitting an enhancement, make sure that you have written unit tests to show
+When adding a new feature, make sure that you have written unit tests to show
 the feature triggers the new behavior when it should, and to show the
 feature does not trigger when it shouldn't. After any code change, make
 sure that the entire test suite passes.

android/Project-maintenance.md

@@ -61,7 +61,7 @@ We also have a [LinkedIn page](https://www.linkedin.com/company/wikimedia-common
 
 - Every major release (e.g. 2.6) should be pulled from main and a new branch created (e.g. `2.6.x-release`)
 - Hotfixes to the major release must be done in the `2.6.x-release` branch, not in main
-- Hotfix releases (e.g. 2.6.1) will be pulled from the `2.6.x-release` branch. New changes/enhancements to main will not be included in the hotfix release
+- Hotfix releases (e.g. 2.6.1) will be pulled from the `2.6.x-release` branch. New changes/features to main will not be included in the hotfix release
 - Release branches will be merged into main periodically (so main is up to date with hotfixes made to release branches)
 - Hotfixes can be released to production after being tested in beta for a few days. Major releases on the other hand should be tested in beta for a much longer time (e.g. 2 weeks?)
 

android/Volunteers-welcome!.md

@@ -6,7 +6,7 @@ We are always looking for volunteers, feel free to step in! It's very easy to ge
 
 1. Set up your working environment by following the [quick start guide](Quick-start-guide-for-Developers.md).
 2. Choose an [unassigned bug](https://github.com/commons-app/apps-android-commons/issues?q=is%3Aissue%20state%3Aopen%20type%3ABug%20no%3Aassignee%20-label%3A%22low%20priority%22%20-label%3Adebated%20-label%3Aupstream) that sounds interesting to you, and ask to be assigned the issue. If the issue was assigned to someone who has been inactive for over 1 month, you can bring this to the attention of collaborators who may ping them for updates and possibly re-assign the issue to you.
-    - If you are a new contributor, please only ask to be assigned to issues with a "bug" or "good first issue" label. Issues labeled "enhancement" will usually only be assigned to contributors with **more than 5 merged pull requests** to this repo. Exceptions may be granted if multiple collaborators agree, but it will take time for approval. ([rationale](https://github.com/commons-app/apps-android-commons/issues/2553))
+    - If you are a new contributor, please only ask to be assigned to issues with a "Bug" type or "good first issue" label. Issues of type "Feature" will usually only be assigned to contributors with **more than 5 merged pull requests** to this repo. Exceptions may be granted if multiple collaborators agree, but it will take time for approval. ([rationale](https://github.com/commons-app/apps-android-commons/issues/2553))
 4. Follow the [Contributing Guidelines](Contributing-Guidelines.md).
 
 It is also recommended that you actually try the app and upload pictures with the app. Become familiar with the various workflows. Notice what kind of categories are suggested depending on where the picture is taken or what you type. Check what people consider [excellent pictures](https://commons.wikimedia.org/wiki/Commons:Featured_pictures) and get inspired by their rich descriptions and accurate categories.

android/gsoc.md

@@ -41,7 +41,7 @@ Thank you for your interest! In the candidate selection phase of GSoC, we ask yo
     - Project Technologies: Android, Java, Kotlin, SQL
     - Project Topics: UI, UX, database
 8. (_Optionally, you can fix more bugs, and add them to your proposal_)
-9. (_Optionally, after 5 bugfixes, you can also work on enhancements, and add them to your proposal. Please stay aware that quality is better than quantity, though._)
+9. (_Optionally, after 5 bugfixes, you can also work on features, and add them to your proposal. Please stay aware that quality is better than quantity, though._)
 
 <!--
 # Task ideas