deploy: 756599b

.buildinfo

@@ -0,0 +1,4 @@
+# Sphinx build info version 1
+# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
+config: 728f777a52acb3b05bb605e9ca4dd377
+tags: 645f666f9bcd5a90fca523b33c5a78b7

_sources/contribute/code-guide.md

@@ -0,0 +1,144 @@
+# Code Contribition Guideline
+
+## General
+* DRY Principle: Do Not Repeat Yourself. Avoid code duplication by reusing components, functions, and styles. This not only minimizes the codebase but also simplifies maintenance and updates.
+* If you are adding code that will be custom to a single platform, the feature needs to be approved by the Wild Me team. If approved, add all custom code in a block at the bottom of the page to prevent merge conflicts.
+
+### Dependencies
+We use dependabot for dependency management; however, due to inconsistencies in semantic versioning and behavioral changes in packages supporting machine learning, we do system testing for all PRs suggested by dependabot. If you want to update or add a new dependency, contact the Wild Me team to discuss the changes before submitting a PR. 
+
+### In-line styling
+Generally speaking, we want to avoid in-line styling to allow for greater consistency and understandability. If you have concerns with what theme styling to use, check the theme figma.
+
+### Internationalization
+All Wild Me tools are intended for an international audience, so we want to provide translated versions. An active goal for 2024 is to get ensure that all product copy has been internationalized according to the following standard.
+
+At present, in Wildbook, all copy except for site name, notification messages, and species names are wrapped and localized to 4 languages: english, french, spanish, and italian.
+
+## Wildbook
+Presently, Wildbook is a tomcat application leveraging jsp as the frontend. We are transitioning to a react frontend with a standardized REST API framework. We are iteratively removing jsp pages. For more details on the trajectory of page updates, see the roadmap.
+
+### Variable naming conventions
+* Camel case
+* Don’t use single-letter variable names (no matter how temporary you think the code is)
+* Code should be clear enough to speak for itself without comments, but use your judgement on if a comment is necessary
+* Code for clarity rather than for efficiency (one-liners are cool, but not at the expense of future obfuscation)
+
+### Notes during modernization
+Because we are transitioning between tech stacks, there are some places where code is weird or where duplicate effort is necessary to maintain user experience.
+* If updating the header, you will need to update:
+  * `header.jsp`
+  * `header.jsx`
+  * `servletResponseTemplate.htm`
+* If changing a dropdown in a .jsp page, use the library `select 2`. It provides a single line component update that adds in the ability to filter the dropdown. For example: `$('#selectCode').select2({width: '100%'});`
+
+### React
+* _Prefer Bootstrap Classes_: Always use Bootstrap's utility classes for styling when possible. This ensures consistency across the project and leverages Bootstrap's responsive features. Only use custom CSS or inline styles when the desired styling cannot be achieved with Bootstrap.
+* _Code Consistency_: We are using eslint and prettier to enforce a consistent coding style throughout the project. This includes consistent naming conventions, file and folder structure, and code formatting.
+* _Componentization_: Break down the UI into reusable components to maximize code reusability and clarity. Each component should have a well-defined purpose and should operate independently as much as possible.
+* _State Management_: Carefully manage state to avoid unnecessary re-renders. Use local state (with `useState`) for data that affects only one component, and consider using context or state management libraries (like Redux or MobX) for shared state across many components.
+* _UseEffect Best Practices_: When using `useEffect`, always include all dependencies in the dependency array to avoid bugs related to stale state and props. Also, be sure to return a cleanup function to avoid memory leaks, especially when subscribing to external data sources.
+* _Props Validation_: Use `PropTypes` to validate props passed to a component, or consider using TypeScript for static type checking throughout the application. This can prevent many runtime errors and improve developer productivity.
+
+#### Tip and Tricks
+* If bootstrap components are stubbornly refusing to change color, try `accent-color`.
+
+### Language files
+`.properties` files in the `resources/bundles` language folders are used to generate translations for different supported languages. If you add a new string to the system, add the string to the appropriate `.properties` file, and make sure the string is available across `en`, `de`, `es`, `fr`, and `it`. Either provide the English string in all files, or provide the translated string in each one.
+
+If you are updating a translation for general use, do your PR against the `master` branch. If you are updating a language file to have specific copy associated with a specific platform, do your PR against the specific platform's branch.
+
+### Java/jsp style
+Initialize variables and type signatures at the abstract/interface level when possible.
+
+Instead of:
+
+```
+ArrayList encounters = new ArrayList<Encounter>();
+...
+public int getMax(ArrayList<int> numbers) {
+```
+
+Try:
+
+```
+List encounters = new ArrayList<Encounter>();
+...
+public int getMax(Collection<int> numbers) {
+```
+
+It’s easier to read and more intuitive for a function to take a Map or List than a HashMap or ArrayList.
+
+The List interface defines how we want that variable to behave, and whether it’s an ArrayList or LinkedList is incidental. Keeping the variable and method signatures abstract means we can change the implementation later (eg swapping ArrayList->LinkedList) without changing the rest of our code.
+https://stackoverflow.com/questions/2279030/type-list-vs-type-arraylist-in-java
+
+Related: when writing utility methods, making the input type as abstract as possible makes the method versatile. See Util.asSortedList in Wildbook: since the input is an abstract Collection, it can accept a List, Set, PriorityQueue, or Vector as input, and return a sorted List.
+
+Runtime (not style): Use Sets (not Lists or arrays) if you’re only keeping track of collection membership / item uniqueness. 
+
+Instead of:
+
+```
+    	List<MarkedIndividual> uniqueIndividuals = new ArrayList<MarkedIndividual>();
+    	for(Encounter currentEncounter: encounters){
+		MarkedIndividual currentInd = enc.getIndividual();
+		if !(uniqueIndividuals.contains(currentInd) {
+			uniqueIndividuals.add(currentInd);
+			doStuff();
+```
+      			
+Try:
+
+```
+Set<MarkedIndividual> uniqueIndividuals = new HashSet<MarkedIndividual>();	
+    	for(Encounter currentEncounter: encounters){
+		MarkedIndividual currentInd = enc.getIndividual();
+		if !(uniqueIndividuals.contains(currentInd) {
+			uniqueIndividuals.add(currentInd);
+			doStuff();
+```
+
+The reason is a little deep in the data types. Sets are defined as unordered collections of unique elements; and Lists/arrays are ordered collections with no bearing on element-uniqueness. If the order of a collection doesn’t matter and you’re just checking membership, you’ll have faster runtime using a Set.
+
+Sets implement contains, add, and remove methods much faster than lists [contains is O(log(n)) vs O(n) runtime]. A list has to iterate through the entire list every time it runs contains (it checks each item once at a time) while a set (especially a HashSet) keeps track of an item index for quick lookup.
+
+
+Use for-each loops aka “enhanced for loops” to make loops more concise and readable.
+
+Instead of:
+
+```
+for (int i=0; i<encounters.length(); i++) {
+	Encounter enc = encounters.get(i)
+	doStuff();
+```
+
+try:
+
+```
+for (Encounter enc: encounters) {
+	doStuff();
+```
+
+Note that in both cases you might want to check if `encounters == null` if relevant, but you rarely need to check if `encounters.length()>0` because the for-loops take care of that.
+
+Also note that if you want access to the `i` variable for logging or otherwise, the classic for-loop is best.
+
+
+`Util.stringExists` is shorthand for a common string check:
+
+Instead of:
+
+```
+	if (str!=Null && !str.equals("")) {
+		doStuff();
+```
+
+Try:
+
+```
+	if (Util.stringExists(str)) {
+		doStuff();
+```
+
+This method also checks for the strings “none” and “unknown” which have given us trouble in displays in the past.

_sources/contribute/index.md

@@ -0,0 +1,32 @@
+# Ways to Contribute
+
+```{toctree}
+:hidden:
+
+pr-workflow
+code-guide
+roadmap
+```
+
+```{note}
+We currently only support development setup on Linux (Ubuntu), but will do our best to support Windows and Mac developers.
+```
+
+Wildbook is open source software intended to combat extinction. While historically considered open repo software, where anyone was free to download and modify the tools, the team has adopted new methods as climate change accelerates. We are working to build a thriving open source community of users, researchers, and developers alike who rely on each other to advance the mission of protecting the planet. 
+
+If you want to help, there's any number of ways that contribute directly to the mission.
+
+* Provide data: If you have relevant species data that you want to provide to researchers, check out the available Wildbooks and see if there's a match. We're also putting together a list of high-interest data deficient species
+* Develop code: unit tests, tech debt, new features, bug fixes. All of our products are available for direct contribution. See the Pull request workflow for more information.
+* Donate: As a non-profit, we are working to provide maximum value at minimum cost. However, we must still cover the costs of things such as storage and processing for our various platforms. 
+
+## Add to documentation
+All Wild Me documentation, be it community, user, or developer docs, is hosted on GitHub. As such, you can contribute to the docunentation through the standard PR flow.
+
+_Guidelines coming soon_
+
+## Coming soon...
+* Test and issue reporting
+* API documentation
+* System and documentation translations
+* ML training and development

_sources/contribute/pr-workflow.md

@@ -0,0 +1,76 @@
+# Pull Request Workflow
+
+All contributions should be made from a fork off of the Wildbook repo. While there are a number of repositories for specific Wildbook communities, large scale development is driven from the main repository. 
+
+## Fork Wildbook
+To start, you will need to be signed in to your GitHub account, have admin access to your OS's terminal, and have Git installed.
+1. From your browser, in the top right corner of the [Wildbook repo](https://github.com/WildMeOrg/Wildbook), click the **Fork** button. Confirm to be redirected to your own fork (check the url for your USERNAME in the namespace).
+1. In your terminal, enter the command `git clone https://github.com/USERNAME/Wildbook.git`
+1. Once the Wildbook directory becomes available in your working directory, move to it with the command `cd Wildbook`
+1. Add a reference to the original repo, denoting it as the upstream repo.
+```
+git remote add upstream https://github.com/WildMeOrg/Wildbook
+git fetch upstream
+```
+
+_Note: The same forking process is used for [WildbookExport](https://github.com/WildMeOrg/WildbookExport)._
+
+## Create Local Branch
+You will want to work in a branch when doing any feature development you want to provide to the original project.
+1. Verify you are on the master branch. The branch you have checked out will be used as the base for your new branch, so you typically want to start from master.
+`git checkout master`
+1. Create your feature branch. It can be helpful to include the issue number (ISSUENUMBER) you are working to address.
+`git branch ISSUENUMBER-FEATUREBRANCHNAME`
+1. Change to your feature branch so your changes are grouped together.
+`git checkout ISSUENUMBER-FEATUREBRANCHNAME`
+1. Update your branch (this is not needed if you just created new branch, but is a good habit to get into).
+` git pull upstream master`
+
+_Note: The primary branch you'll be working from for Scout or WildbookExport is `main`._
+
+## Set Up Development Environment with Docker
+For easiest development, you will need to set up your development environment to work with Docker. See `devops/development/README.md` for detailed instructions.
+
+## Deploy frontend
+To setup frontend, we need to deploy the React build to Wildbook, please follow the detailed instructions provided in the `frontend/README.md` file within the project directory.
+
+## Making Local Changes
+Make the code changes necessary for the issue you're working on. The following git commands may prove useful.
+
+* `git log`: lastest commits of current branch
+* `git status`: current staged and unstaged modifications
+* `git diff --staged`:  the differences between the staging area and the last commit
+* `git add <filename>: add files that have changes to staging in preparation for commit
+* `git commit`: commits the stagged files, opens a text editor for you to write a commit log
+
+## Submit PR
+Up to this point, all changes have been done to your local copy of Wildbook. You need to push the new commits to a remote branch to start the PR process.
+
+1. Now's the time clean up your PR if you choose to squash commits, but this is not required. If you're looking for more information on these practices, see this [pull request tutorial](https://yangsu.github.io/pull-request-tutorial/).
+1. Push to the remote version of your branch ` git push <remote> <local branch>`
+`git push origin ISSUENUMBER-FEATUREBRANCHNAME`
+1. When prompted, provide your username and GitHub Personal Access Token. If you do not have a GitHub Personal Access Token, or do not have one with the correct permissions for your newly forked repository, you will need to [create a Personal Access Token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token).
+1. Check the fork's page on GitHub to verify that you see a new branch with your added commits. You should see a line saying "This branch is X commits ahead" and a **Pull request** link. 
+1. Click the **Pull request** link to open a form that says "Able to merge". (If it says there are merge conflicts, go the  for help).
+1. Use an explicit title for the PR and provide details in the comment area. Details can include text, or images, and should provide details as to what was done and why design decisions were made.
+1. Click **Create a pull request**. 
+
+## Respond to feedback
+At this point, it's on us to get you feedback on your submission! Someone from the Wild Me team will review the project and provide any feedback that may be necessary. If changes are recommended, you'll need to checkout the branch you were working from, update the branch, and make these changes locally.
+
+1. `git checkout ISSUENUMBER-FEATUREBRANCHNAME`
+1. `git pull upstream master`
+1. Make required changes
+1. `git add <filename>` for all files impacted by changes
+1. Determine which method would be most appropriate for updating your PR  
+  * `git commit --ammend` if the changes are small stylistic changes
+  * `git commit` if the changes involved significant rework and require additional details
+
+## Other branches
+The code for specific Wildbook platforms is available in different branches under the Wildbook repo. The only contributions made to these repos are:
+* standardizations by the Wild Me team to get rid of historical custom code
+* merges of master into the branch by the Wild Me team
+* updates to `.properties` files, such as translations, custom fields, or species management
+* updates to `IA.json` to manage locationIDs available in the system
+
+All custom feature work that is pushed to a non-`master` branch will be closed unless discussed and approved by the Wild Me team in advance.

_sources/contribute/roadmap.md

@@ -0,0 +1,37 @@
+# Roadmap
+The roadmaps below are rough outlines of our objectives. We operate by milestones, and sometimes things change dramatically because of technical limitations or pressing issues reported by users.
+
+## Wildbook
+We are working on a improve-and-refresh objective. We want to improve on the user experience of Wildbook platform users with each release while also making the technology more accessible to the development community and indepedent installers. As such, we trade off a major feature release with a timeboxed tech debt release. We plan to continue this cadence through the end of 2024.
+
+### 10.3.0
+Feature focused release.
+* Improve encounter search through OpenSearch integration. Better indexing for large scale platforms, and integration open source technology allows for continuous improvement rather than our home-spun search.
+* Feedback from 10.2.0 indicates that we need to smooth  the transition for the React changeover. We'll start by matching the header between react and jsp, giving a consistent navigation experience on all pages.
+* Fix Wildbook docker update so it updates on every release. Has been broken for several years, just needs the attention on it.
+* Documentation is currently spread out between different formats and locations. Consolidated Wildbook/Scout/contributor documentation release that allows for direct contribution will reduce overhead for all doc management.
+
+### 10.4.0
+Tech debt release.
+* Remove adoptions functionality, which is a support burden and does not function as a revenue stream.
+* Setup the default Wildbook information to be site-neutral, allowing users to set up their own Wildbooks more easily.
+
+### 10.5.0
+Feature focused release.
+* One search. Index Sighting and Individual information using OpenSearch
+* Custom field support.
+
+### 10.6.0
+Tech debt release.
+* Transition platform fields to custom field structure.
+
+### 10.7.0
+Feature focused release.
+* Bulk import refresh. Leverage an open source technology that allows for column mapping and provides clear validation before submission.
+
+## Scout
+Because Scout started as a tool to support a single project, We are working to broaden the usage by making it a more generalized tool. We want to improve the workflow management and annotation interface.
+
+### 2.2.0
+
+### 2.3.0