From 33d56fdcd17797519dcb569ac6be8cf48c6e7c9e Mon Sep 17 00:00:00 2001 From: Raymond Hughes <131811099+raymond-hughes@users.noreply.github.com> Date: Tue, 1 Oct 2024 22:06:10 -0400 Subject: [PATCH] Master to Main documentation changes (#23034) * Update WINDOWS_11.md replacing master with main * References to master are changed to main where applicable --- .github/ISSUE_TEMPLATE/tech-spec.md | 14 ++-- .github/workflows/main.yml | 10 +-- .github/workflows/make-docs.yml | 4 +- Dangerfile | 2 +- Jenkinsfile | 8 +-- MAC_M1.md | 6 +- Makefile.example | 6 +- PULL_REQUEST_TEMPLATE.md | 4 +- README.md | 8 +-- WINDOWS_11.md | 2 +- app/controllers/route_docs_controller.rb | 2 +- ...process_notification_status_updates_job.rb | 2 +- app/models/tasks/timed_hold_task.rb | 2 +- .../generate_hearing_days_schedule.rb | 2 +- client/app/components/SearchBar.stories.mdx | 4 +- .../components/StyleGuideComponentTitle.jsx | 2 +- .../StyleGuide/StyleGuideDashboard.jsx | 2 +- .../caseEvaluation/EvaluateDecisionView.jsx | 4 +- client/app/util/ApiUtil.js | 4 +- client/package.json | 2 +- .../tech-specs/2018-05-18-hearing-schedule.md | 48 +++++++------- .../2018-06-21-vacols-caseflow-transition.md | 66 +++++++++---------- .../2018-08-16-slotting-veterans.md | 20 +++--- .../2018-11-14-schedule-hearing-task.md | 10 +-- ...2018-11-16-co-parent-records-transition.md | 10 +-- .../2018-11-28-legacy-issue-establishment.md | 8 +-- .../2018-11-30-alternate-hearing-locations.md | 10 +-- ...8-12-06-legacy-issue-optin-and-rollback.md | 4 +- .../2019-01-28-hearing-task-flow.md | 22 +++---- .../2019-04-11-hearing-prep-merge.md | 12 ++-- .../2019-08-01-establish-930-corrections.md | 2 +- ...9-10-10-integrating-caseflow-with-pexip.md | 8 +-- docs/tech-specs/README.md | 4 +- scripts/dev_env_setup_step1.sh | 2 +- scripts/dev_env_setup_step2.sh | 4 +- scripts/whats-next | 2 +- spec/rails_helper.rb | 2 +- 37 files changed, 162 insertions(+), 162 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/tech-spec.md b/.github/ISSUE_TEMPLATE/tech-spec.md index 578fc5bf57f..64bcc762737 100644 --- a/.github/ISSUE_TEMPLATE/tech-spec.md +++ b/.github/ISSUE_TEMPLATE/tech-spec.md @@ -8,16 +8,16 @@ assignees: '' --- # Tech Spec Title -**Drafter**: -**Discussion Meeting**: +**Drafter**: +**Discussion Meeting**: ## Context - @@ -31,11 +31,11 @@ Who are the stakeholders? --> ## Open Questions - ## Implementation Options - 1. Go to [Jira Issue/Test Plan Link](https://jira.devops.va.gov/browse/JIRA-12345) or list them below -- [ ] For feature branches merging into master: Was this deployed to UAT? +- [ ] For feature branches merging into main: Was this deployed to UAT? # Frontend ## User Facing Changes @@ -31,7 +31,7 @@ Please explain the changes you made here. *Only for Schema Changes* * [ ] Add typical timestamps (`created_at`, `updated_at`) for new tables -* [ ] Update column comments; include a "PII" prefix to indicate definite or potential [PII data content](https://github.com/department-of-veterans-affairs/appeals-team/blob/master/caseflow-team/0-how-we-work/pii-handbook.md#what-is-pii) +* [ ] Update column comments; include a "PII" prefix to indicate definite or potential [PII data content](https://github.com/department-of-veterans-affairs/appeals-team/blob/main/caseflow-team/0-how-we-work/pii-handbook.md#what-is-pii) * [ ] Have your migration classes inherit from `Caseflow::Migration`, especially when adding indexes (use `add_safe_index`) (see [Writing DB migrations](https://github.com/department-of-veterans-affairs/caseflow/wiki/Writing-DB-migrations)) * [ ] Verify that `migrate:rollback` works as desired ([`change` supported functions](https://edgeguides.rubyonrails.org/active_record_migrations.html#using-the-change-method)) * [ ] Perform query profiling (eyeball Rails log, check bullet and fasterer output) diff --git a/README.md b/README.md index 281703aa1e2..334b3ea2751 100644 --- a/README.md +++ b/README.md @@ -156,7 +156,7 @@ First you'll need to install ansible-vault and credstash. pip install ansible-vault pip install credstash ``` -For more credstash setup, follow [the doc](https://github.com/department-of-veterans-affairs/appeals-deployment/blob/master/docs/credstash.md#using-credstash) +For more credstash setup, follow [the doc](https://github.com/department-of-veterans-affairs/appeals-deployment/blob/main/docs/credstash.md#using-credstash) We'll need to obtain the Ansible vault password using credstash: @@ -267,8 +267,8 @@ Rails.cache.write(:degraded_service_banner, :auto) We have a lot of technical documentation spread over a lot of different repositories. Here is a non-exhaustive mapping of where to find documentation: -- [Local Caseflow Setup](https://github.com/department-of-veterans-affairs/caseflow/tree/master/docs) +- [Local Caseflow Setup](https://github.com/department-of-veterans-affairs/caseflow/tree/main/docs) - [Test data setup in lower environments](https://github.com/department-of-veterans-affairs/appeals-qa/tree/master/docs) -- [Caseflow specific devops documentation](https://github.com/department-of-veterans-affairs/appeals-deployment/tree/master/docs) This folder also contains our [first responder manual](https://github.com/department-of-veterans-affairs/appeals-deployment/blob/master/docs/first-responder-manual.md), which is super in understanding our production systems. +- [Caseflow specific devops documentation](https://github.com/department-of-veterans-affairs/appeals-deployment/tree/main/docs) This folder also contains our [first responder manual](https://github.com/department-of-veterans-affairs/appeals-deployment/blob/main/docs/first-responder-manual.md), which is super in understanding our production systems. - [Non-Caseflow specific devops documentation](https://github.com/department-of-veterans-affairs/devops/tree/master/docs). This documentation is shared with the vets.gov team, so not all of it is relevant. -- [Project documentation](https://github.com/department-of-veterans-affairs/appeals-design-research/tree/master/Project%20Folders) +- [Project documentation](https://github.com/department-of-veterans-affairs/appeals-design-research/tree/main/Project%20Folders) diff --git a/WINDOWS_11.md b/WINDOWS_11.md index 8d7f388a3d9..f7ec6fe1e08 100644 --- a/WINDOWS_11.md +++ b/WINDOWS_11.md @@ -130,7 +130,7 @@ Run each line is a separate command, run them one at a time 24. Close and restart VS Code -25. branch should be up to date with master (```git checkout master```, ```git pull```) +25. branch should be up to date with main (```git checkout main```, ```git pull```) 26. ```cd ~/appeals/caseflow in terminal``` diff --git a/app/controllers/route_docs_controller.rb b/app/controllers/route_docs_controller.rb index 99df04daf33..b51474ea25b 100644 --- a/app/controllers/route_docs_controller.rb +++ b/app/controllers/route_docs_controller.rb @@ -2,7 +2,7 @@ class RouteDocsController < ApplicationController class DocumentedRoute - SOURCE_URL_PREFIX = "https://github.com/department-of-veterans-affairs/caseflow/blob/master/app/controllers/" + SOURCE_URL_PREFIX = "https://github.com/department-of-veterans-affairs/caseflow/blob/main/app/controllers/" attr_reader :rails_route diff --git a/app/jobs/process_notification_status_updates_job.rb b/app/jobs/process_notification_status_updates_job.rb index 7c8571c8c6a..990596f9339 100644 --- a/app/jobs/process_notification_status_updates_job.rb +++ b/app/jobs/process_notification_status_updates_job.rb @@ -62,7 +62,7 @@ def recv_queue_url # and consume the data in order to persist VA Notify status updates to the # the notifications table. # - # @see https://github.com/department-of-veterans-affairs/caseflow/blob/master/app/controllers/api/v1/va_notify_controller.rb + # @see https://github.com/department-of-veterans-affairs/caseflow/blob/main/app/controllers/api/v1/va_notify_controller.rb # # @return [Integer] # The number of messages that were attempted to be processed in a batch. diff --git a/app/models/tasks/timed_hold_task.rb b/app/models/tasks/timed_hold_task.rb index 6399711c994..0363dc0786e 100644 --- a/app/models/tasks/timed_hold_task.rb +++ b/app/models/tasks/timed_hold_task.rb @@ -55,7 +55,7 @@ def timer_end_time # Since we expect to always instantiate TimedHoldTasks with a delay we need to take that into account # to know when the timer will complete. # - # https://github.com/department-of-veterans-affairs/caseflow/blob/master/app/models/concerns/asyncable.rb#L125 + # https://github.com/department-of-veterans-affairs/caseflow/blob/main/app/models/concerns/asyncable.rb#L125 # # If we allow TimedHoldTasks to be submitted without delay this will need to change. task_timers.first ? task_timers.first.last_submitted_at + TaskTimer.processing_retry_interval_hours.hours : nil diff --git a/app/services/hearing_schedule/generate_hearing_days_schedule.rb b/app/services/hearing_schedule/generate_hearing_days_schedule.rb index f796fa05ef8..f236cf05998 100644 --- a/app/services/hearing_schedule/generate_hearing_days_schedule.rb +++ b/app/services/hearing_schedule/generate_hearing_days_schedule.rb @@ -5,7 +5,7 @@ # video hearings and CO hearings in a specified date range after filtering out weekends, # holidays, and board non-availability dates. Full details of the algorithm can be # found `HearingSchedule.md` in Appeals-team repo (link: https://github.com/department-of-veterans-affairs/appeals-team/ -# blob/master/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Tech%20Specs/HearingSchedule.md). +# blob/main/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Tech%20Specs/HearingSchedule.md). # WIKI : https://github.com/department-of-veterans-affairs/caseflow/wiki/Caseflow-Hearings#build-hearing-schedule ## class HearingSchedule::GenerateHearingDaysSchedule diff --git a/client/app/components/SearchBar.stories.mdx b/client/app/components/SearchBar.stories.mdx index ec6b174bda9..642b75ac6cf 100644 --- a/client/app/components/SearchBar.stories.mdx +++ b/client/app/components/SearchBar.stories.mdx @@ -56,7 +56,7 @@ Labels can be set with the `title` property. ## Internal Text Text can be set and shown inside of the search bar with the `internalText` property. This can be used to show extra -information about the search. Check out [`DocumentSearch#getInternalText`](https://github.com/department-of-veterans-affairs/caseflow/blob/master/client%2Fapp%2Freader%2FDocumentSearch.jsx#L118) +information about the search. Check out [`DocumentSearch#getInternalText`](https://github.com/department-of-veterans-affairs/caseflow/blob/main/client%2Fapp%2Freader%2FDocumentSearch.jsx#L118) to see how we change this field dynamically as the user types to display the number of results. @@ -82,4 +82,4 @@ disabled and shows a loading icon while waiting for results. ## Args - \ No newline at end of file + diff --git a/client/app/components/StyleGuideComponentTitle.jsx b/client/app/components/StyleGuideComponentTitle.jsx index ba86ade3691..f286906d9cd 100644 --- a/client/app/components/StyleGuideComponentTitle.jsx +++ b/client/app/components/StyleGuideComponentTitle.jsx @@ -20,7 +20,7 @@ export default class StyleGuideComponentTitle extends React.PureComponent { // isExternalLink is for any code sample that's outside the StyleGuide container directory baseUrl = 'https://github.com/department-of-veterans-affairs/caseflow'; } else { - baseUrl = 'https://github.com/department-of-veterans-affairs/caseflow/blob/master/client/app/containers/StyleGuide/'; + baseUrl = 'https://github.com/department-of-veterans-affairs/caseflow/blob/main/client/app/containers/StyleGuide/'; } /* eslint-enable max-len */ diff --git a/client/app/containers/StyleGuide/StyleGuideDashboard.jsx b/client/app/containers/StyleGuide/StyleGuideDashboard.jsx index 547406d7f57..13c7448983c 100644 --- a/client/app/containers/StyleGuide/StyleGuideDashboard.jsx +++ b/client/app/containers/StyleGuide/StyleGuideDashboard.jsx @@ -8,7 +8,7 @@ export default class StyleGuideDashboard extends React.PureComponent {

diff --git a/client/app/queue/caseEvaluation/EvaluateDecisionView.jsx b/client/app/queue/caseEvaluation/EvaluateDecisionView.jsx index 60d48ea53e5..9dc32c135c9 100644 --- a/client/app/queue/caseEvaluation/EvaluateDecisionView.jsx +++ b/client/app/queue/caseEvaluation/EvaluateDecisionView.jsx @@ -308,8 +308,8 @@ const mapStateToProps = (state, ownProps) => { // previousTaskAssignedOn comes from // eslint-disable-next-line max-len - // Legacy: https://github.com/department-of-veterans-affairs/caseflow/blob/master/app/models/legacy_tasks/judge_legacy_task.rb#L17 - // AMA: https://github.com/department-of-veterans-affairs/caseflow/blob/master/app/models/tasks/judge_task.rb#L42 + // Legacy: https://github.com/department-of-veterans-affairs/caseflow/blob/main/app/models/legacy_tasks/judge_legacy_task.rb#L17 + // AMA: https://github.com/department-of-veterans-affairs/caseflow/blob/main/app/models/tasks/judge_task.rb#L42 const judgeDecisionReviewTask = taskById(state, { taskId: ownProps.taskId }); // When canceling out of Evaluate Decision page need to check if appeal exists otherwise failures occur diff --git a/client/app/util/ApiUtil.js b/client/app/util/ApiUtil.js index 3e4a03540ce..37e8341c554 100644 --- a/client/app/util/ApiUtil.js +++ b/client/app/util/ApiUtil.js @@ -65,7 +65,7 @@ const errorHandling = (url, error, method, options = {}) => { options.end = moment().format(); options.duration = options.t1 - options.t0; - // Need to renable this check before going to master + // Need to renable this check before going to main if (options?.metricsLogRestError) { const data = { metric: { @@ -95,7 +95,7 @@ const successHandling = (url, res, method, options = {}) => { const id = uuid.v4(); const message = `UUID: ${id}.\nSuccess with ${method} ${url}.\n${res.status}`; - // Need to renable this check before going to master + // Need to renable this check before going to main options.t1 = performance.now(); options.end = moment().format(); options.duration = options.t1 - options.t0; diff --git a/client/package.json b/client/package.json index e467682a45f..820ec8426d5 100644 --- a/client/package.json +++ b/client/package.json @@ -15,7 +15,7 @@ "test:jest:watch": "NODE_ENV=test jest --watch", "test:jest:update": "NODE_ENV=test jest --updateSnapshot", "test:legacy:watch": "yarn run test:legacy --watch", - "lint": "eslint --max-warnings 0 --cache $(git diff --name-only --diff-filter=d --relative $(git merge-base $(git rev-parse --abbrev-ref HEAD) origin/master) *.js *.jsx)", + "lint": "eslint --max-warnings 0 --cache $(git diff --name-only --diff-filter=d --relative $(git merge-base $(git rev-parse --abbrev-ref HEAD) origin/main) *.js *.jsx)", "lint:fix": "yarn run lint --fix", "pretty": "yarn run prettier constants/TASK_ACTIONS.json", "pretty:check": "yarn run pretty --check", diff --git a/docs/tech-specs/2018-05-18-hearing-schedule.md b/docs/tech-specs/2018-05-18-hearing-schedule.md index 5a51355e4b3..076c8c5c97d 100644 --- a/docs/tech-specs/2018-05-18-hearing-schedule.md +++ b/docs/tech-specs/2018-05-18-hearing-schedule.md @@ -1,11 +1,11 @@ -This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/master/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Tech%20Specs/HearingSchedule.md). +This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/main/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Tech%20Specs/HearingSchedule.md). ## Caseflow Hearing Schedule -Owner: Sharon Warner -Date: 2018-05-18 -Reviewer(s): -Review by: +Owner: Sharon Warner +Date: 2018-05-18 +Reviewer(s): +Review by: ## Context @@ -64,9 +64,9 @@ Because of the tight deadline, and the amount of data we need to input, we're go 1) Hearings allocation 1) Judge non-availability dates -The RO non-availability dates, board non-availability dates, and hearings allocation will be uploaded together semi-annually, and the judge non-availability dates will be uploaded separately quarterly. The spreadsheet templates can be found [here](https://github.com/department-of-veterans-affairs/appeals-team/tree/master/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Designs). +The RO non-availability dates, board non-availability dates, and hearings allocation will be uploaded together semi-annually, and the judge non-availability dates will be uploaded separately quarterly. The spreadsheet templates can be found [here](https://github.com/department-of-veterans-affairs/appeals-team/tree/main/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Designs). -We will pull already-scheduled video and central office hearings and travel board hearings from VACOLS. +We will pull already-scheduled video and central office hearings and travel board hearings from VACOLS. ## Overview - December Release @@ -98,29 +98,29 @@ The NonAvailability table will include information for all three types of non-av Each time a valid spreadsheet is uploaded, we'll record the dates that spreadsheet covers in SchedulePeriods. If a user uploads a second spreadsheet of the same type that covers date that have already been uploaded, we'll check to see if Finalized for the original spreadsheet is true or false. If Finalized is true, that means the information has already been uploaded to VACOLS, and we'll tell the user that they cannot re-upload a spreadsheet for those dates. If Finalized is false, we'll tell the user that they have already uploaded a spreadsheet for those dates and ask if they want to proceed. If the user wants to proceed, we'll delete all information associated with the original spreadsheet and then upload the new spreadsheet. -We'll also check the following validations for each spreadsheet. If the uploaded spreadsheet breaks any of these validations, we'll ask the user to fix the error and re-upload the spreadsheet. - -1) The headers much match the template exactly. +We'll also check the following validations for each spreadsheet. If the uploaded spreadsheet breaks any of these validations, we'll ask the user to fix the error and re-upload the spreadsheet. + +1) The headers much match the template exactly. 1) All dates should all be in this format: mm/dd/yyyy. 1) All dates should be within the date range specified by the hearing coordinator. *RO Non-Availability* -1) All BFREGOFF codes should match the city, state we have listed in regional_office.rb. -1) Every RO listed in regional_office.rb should have a column. -1) The dates listed for each RO should be unique. +1) All BFREGOFF codes should match the city, state we have listed in regional_office.rb. +1) Every RO listed in regional_office.rb should have a column. +1) The dates listed for each RO should be unique. *CO Non-Availability* - -1) The dates should be unique. + +1) The dates should be unique. *Judge Non-Availability* -1) The CSS id and judge name should match what we already have stored in our database. +1) The CSS id and judge name should match what we already have stored in our database. + +*Hearing Allocations* -*Hearing Allocations* - -1) All BFREGOFF codes should match the city, state we have listed in regional_office.rb. -1) Every RO listed in regional_office.rb should have a row. +1) All BFREGOFF codes should match the city, state we have listed in regional_office.rb. +1) Every RO listed in regional_office.rb should have a row. **User Permissions (May)** @@ -155,7 +155,7 @@ We'll create two new buckets within the dsva-appeals-caseflow-prod bucket to sto 2. 2nd source is the travel board dates fetched from VACOLS 4. Divide the number of hearing days for each RO by the number of months selected in the timeframe. (RO1: 12 for 6 months ) -> 2 days per month. 1. It’s preferred to have RO hearing days distributed among the selected months (example: if an RO has 2 hearing days; it’s preferred to have each hearing day distributed among different months) - 2. A priority is given for ROs that have multiple rooms available since they can hold more hearings per day + 2. A priority is given for ROs that have multiple rooms available since they can hold more hearings per day 3. It’s preferred to have whole number hearing days even if the hearing days cannot be evenly distributed ~ (if an RO has 25 hearing days, 25/6 = 4.16, each month shall have at least 4 hearing days for this RO and the remainder of days can be distributed among random months selected based on the calendar days available to the RO). 4. If the RO hearing days cannot be distributed evenly among the selected months due to increased non-availability days for the month, the remaining hearings are distributed through out the other months based on the available calendars days for the RO) 5. Select a random RO available date in the month to assign each of the divided RO hearing days. @@ -194,8 +194,8 @@ To support querying for Travel Board hearings we need to add the following opera 2. If a judge is on a travel board, it’s for an entire week 1. No RO hearing days can be allocated to that judge a week prior or after the travel board week. -Notes: -There are three options for allocating judges: +Notes: +There are three options for allocating judges: 1. Shuffle the judges and allocate the hearing days one at a time to all the judges (It doesn't verify complete balance, since it's randomized for the current scheduled period) 2. Fetch all hearing days for all judges for the current federal fiscal year, allocate the hearing days to initially to the judges with the least amount of hearings to make sure the hearing days are evently distributed to all judges. @@ -214,7 +214,7 @@ Example error: **August Rollout** -Unfortunately, the hearing coordinators are required to build the schedule for the first six months of FY2019 before our August 1st roll-out date. However, the hearing coordinators will use Caseflow to assign those hearing days to judges and to build the schedule for the second six months of FY2019. +Unfortunately, the hearing coordinators are required to build the schedule for the first six months of FY2019 before our August 1st roll-out date. However, the hearing coordinators will use Caseflow to assign those hearing days to judges and to build the schedule for the second six months of FY2019. We will also create a test case that the hearing coordinators can use to create a mock hearing schedule for the first six months of FY2019. They can compare this mock schedule to the schedule they have already manually created to confirm the scheduling is working as expected. diff --git a/docs/tech-specs/2018-06-21-vacols-caseflow-transition.md b/docs/tech-specs/2018-06-21-vacols-caseflow-transition.md index bb0331ed2e9..001e937ad2a 100644 --- a/docs/tech-specs/2018-06-21-vacols-caseflow-transition.md +++ b/docs/tech-specs/2018-06-21-vacols-caseflow-transition.md @@ -1,16 +1,16 @@ -This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/master/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Tech%20Specs/VacolsCaseflowTransition.md). +This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/main/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Tech%20Specs/VacolsCaseflowTransition.md). -## VACOLS to Caseflow Transition +## VACOLS to Caseflow Transition -Owner: Oscar Ramirez -Date: 2018-06-21 (Updated 2018-08-08) -Reviewer(s): Sharon Warner, Alex Prokop -Review by: 2018-08-13 +Owner: Oscar Ramirez +Date: 2018-06-21 (Updated 2018-08-08) +Reviewer(s): Sharon Warner, Alex Prokop +Review by: 2018-08-13 ## Context -Once the AMA legislation goes live on February 14, 2019 the Board will assign appeals to specific hearing days, taking over a task performed by regional offices today. This technical specification outlines the events that need to take place to make this transition of responsibilities as smooth as possible +Once the AMA legislation goes live on February 14, 2019 the Board will assign appeals to specific hearing days, taking over a task performed by regional offices today. This technical specification outlines the events that need to take place to make this transition of responsibilities as smooth as possible -## Overview +## Overview AMA appeals are any appeals processed under the workflow defined by the new legislation. AMA appeals will be processed exclusively in Caseflow, while Legacy appeals will continue to be stored in the VACOLS database. New Legacy Appeals may continue to flow into the system after February of 2019 as Veterans have up to a year to appeal a claim. For the August 2018 release of the Hearing Schedule product the calendar of hearing days allocated to regional offices will be stored in VACOLS. Regional offices will continue to manage slotting appeals to hearing days using the VACOLS UI. @@ -21,7 +21,7 @@ When the AMA legislation is in place the calendar of hearing days will be stored This hearing type is discontinued for AMA appeals but we need to continue to support it while there are legacy appeals that chose this hearing in the system. -A Travel Board Hearing Schedule is very different than the next two types of hearings. They are organized in trips that last several days. Each trip has one or more participants. The participants are one or more judges, and possibly one or more attorneys. +A Travel Board Hearing Schedule is very different than the next two types of hearings. They are organized in trips that last several days. Each trip has one or more participants. The participants are one or more judges, and possibly one or more attorneys. **Central Office Hearings** @@ -33,7 +33,7 @@ These hearings will continue with the AMA legislation. The Veteran travels to a The Board allocates a certain number of hearing days for a Fiscal Year to each regional office based on the number of appeals requiring hearings. -The ER diagram below highlights the different data attributes for each hearing type. +The ER diagram below highlights the different data attributes for each hearing type. ![Data Model](2018-06-21-hearing-schedule-data-model.png) @@ -79,28 +79,28 @@ Once AMA hearings start, the audio files for these hearings may have to be store ## Reports The Hearing Management team is reviewing the existing reports to let us know which continue to be valid and need migration to Caseflow. Their review is ongoing as of this writing. A cursory review of the applications used by the Regional Offices and by Hearing Management reveals the following reports. There may be more but these are the obvious ones directly dealing with hearings data. -vclrpts app -Custom Rpts --> CO, Travel Board, Video Request Summary -Annual Rpts --> BVA Hearings Held - -Vacols3 app -Hearings --> Video Hearings -Hearings --> Travel Board Hearings -Hearings --> CO Hearings - -Roaccess -Hearings --> Travel Board Requests -Hearings --> Formal Hearings Pending -Hearings --> Formal Hearing Disposition Detail -Hearings --> Forman Hearing Disposition Summary -Hearings --> Certified BVA Awaiting Travel Board -Hearings --> BVA VLJs --> Update Travel Board Docket -Hearings --> BVA VLJs --> Update Video Docket <-- Are these used by VLJs or Hearing Coordinators? -Hearings --> BVA VLJs --> Update / Print CO Docket -Hearings --> View/Print Virtual TB or Video Docket - -Mgmt Rpts --> BVA Hearing Schedule (TB, Video, CO) -Mgmt Rpts --> BVA Hearing Disposition Summary by RO +vclrpts app +Custom Rpts --> CO, Travel Board, Video Request Summary +Annual Rpts --> BVA Hearings Held + +Vacols3 app +Hearings --> Video Hearings +Hearings --> Travel Board Hearings +Hearings --> CO Hearings + +Roaccess +Hearings --> Travel Board Requests +Hearings --> Formal Hearings Pending +Hearings --> Formal Hearing Disposition Detail +Hearings --> Forman Hearing Disposition Summary +Hearings --> Certified BVA Awaiting Travel Board +Hearings --> BVA VLJs --> Update Travel Board Docket +Hearings --> BVA VLJs --> Update Video Docket <-- Are these used by VLJs or Hearing Coordinators? +Hearings --> BVA VLJs --> Update / Print CO Docket +Hearings --> View/Print Virtual TB or Video Docket + +Mgmt Rpts --> BVA Hearing Schedule (TB, Video, CO) +Mgmt Rpts --> BVA Hearing Disposition Summary by RO **NB: Outcome of Hearing Management report review may affect the data model as additional attributes may need to be associated with either individual hearings or the schedule.** @@ -112,7 +112,7 @@ Mgmt Rpts --> BVA Hearing Disposition Summary by RO - appeal_id - how do we associate to both LegacyAppeal and Appeal models. - How is team assigned? Do we need it? In VACOLS UI the team field is populated based on what is on the staff table for the judge. - Remove veteran_id as this information can be fetched from the appeal. -- Remove media_type? For hearings since September 2017 there were 25 which used cassette tape. +- Remove media_type? For hearings since September 2017 there were 25 which used cassette tape. - Rename media_problem to recording_problem. - Rename hold_days_vlj to hold_days. Does it generate an alert after n days? - Separate hearing prep data from hearings data? When appeal is rescheduled do we want to keep the hearings detail data? We would move the hearings row and associate it with another HearingDay row. diff --git a/docs/tech-specs/2018-08-16-slotting-veterans.md b/docs/tech-specs/2018-08-16-slotting-veterans.md index 9606276f885..1ad120cfdec 100644 --- a/docs/tech-specs/2018-08-16-slotting-veterans.md +++ b/docs/tech-specs/2018-08-16-slotting-veterans.md @@ -1,11 +1,11 @@ -This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/master/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Tech%20Specs/SlottingVeterans.md). +This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/main/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Tech%20Specs/SlottingVeterans.md). ## Slotting Veterans - October 19th Release -Owner: Sharon Warner -Date: 2018-08-16 -Reviewer(s): -Review by: +Owner: Sharon Warner +Date: 2018-08-16 +Reviewer(s): +Review by: ## Context @@ -18,7 +18,7 @@ While previously, RO hearing coordinators handled assigning veterans to hearing In order to allow our users to slot veterans to hearing days, we will provide two data elements: 1) A list of veterans who are ready for hearings, filtered by RO and hearing type, and sorted by priority and docket order (CAVC, AOD, other) -2) A list of upcoming hearing days, filtered by RO and hearing type, along with the number of available slots +2) A list of upcoming hearing days, filtered by RO and hearing type, along with the number of available slots The hearing coordinators will use these data elements to assign veterans to the appropriate hearing days. We will also build search functionality so hearing coordinators can search for individual cases. @@ -66,12 +66,12 @@ The homepage for this functionality will exist at /hearings/schedule/assign. ## Rollout Plan -**CO Hearings**— This functionality will be released October 19th, 2018. Our first user will be the Central Office Hearing Coordinator at the Board. They will use Caseflow to slot veterans for central office hearings. We confirmed with the Hearings Management Branch that all Central Office appeals to be scheduled area already available in Location 57, which is already part of their normal processes for scheduling CO hearings. +**CO Hearings**— This functionality will be released October 19th, 2018. Our first user will be the Central Office Hearing Coordinator at the Board. They will use Caseflow to slot veterans for central office hearings. We confirmed with the Hearings Management Branch that all Central Office appeals to be scheduled area already available in Location 57, which is already part of their normal processes for scheduling CO hearings. -The Project Management Team will develop training materials and we will schedule a training with the CO Hearing Coordinator. +The Project Management Team will develop training materials and we will schedule a training with the CO Hearing Coordinator. -**One Regional Office** — After successful rollout to Central Office hearings, the board will take over slotting veterans for 1 RO that does not have any alternate hearing locations through Caseflow. For this to work, the Board will need to activate, case review, and move these appeals to Location 57 so that Caseflow can display those Veterans to schedule. +**One Regional Office** — After successful rollout to Central Office hearings, the board will take over slotting veterans for 1 RO that does not have any alternate hearing locations through Caseflow. For this to work, the Board will need to activate, case review, and move these appeals to Location 57 so that Caseflow can display those Veterans to schedule. -**Full Roll out** - On February 14th, 2019, the board will take over slotting veterans for all ROs. The Board will need to have appeals that are ready to be scheduled activated, reviewed, and in location 57. +**Full Roll out** - On February 14th, 2019, the board will take over slotting veterans for all ROs. The Board will need to have appeals that are ready to be scheduled activated, reviewed, and in location 57. ## Research Notes diff --git a/docs/tech-specs/2018-11-14-schedule-hearing-task.md b/docs/tech-specs/2018-11-14-schedule-hearing-task.md index 5b742f0c752..fe2639c8738 100644 --- a/docs/tech-specs/2018-11-14-schedule-hearing-task.md +++ b/docs/tech-specs/2018-11-14-schedule-hearing-task.md @@ -1,14 +1,14 @@ -This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/master/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Tech%20Specs/ScheduleHearingTask.md). +This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/main/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Tech%20Specs/ScheduleHearingTask.md). ## Schedule Hearing Task -Owner: Sharon Warner & Andrew Lomax -Date: 2018-11-14 +Owner: Sharon Warner & Andrew Lomax +Date: 2018-11-14 Reviewers: Lowell Wood ## Context -We are refactoring the way we create Hearing Scheduling tasks on the Case Details page! +We are refactoring the way we create Hearing Scheduling tasks on the Case Details page! Previously, we created a Schedule Hearing task anytime a user navigated to the Case Details page from the Assign Hearings page. Unfortunately this leaves out necessary functionality; for example, sometimes users will navigate to the Case Details page from search and need to schedule a hearing. @@ -16,7 +16,7 @@ To fix this, we are now going to allow Hearings Management Branch users to creat ## Overview -When on the Case Details page, all Hearings Management Branch users will have the ability to create a Schedule Hearing task for the appeal as long as 1) The appeal does not already have a hearing with no disposition, and 2) The appeal does not already have an open Schedule Hearing task. +When on the Case Details page, all Hearings Management Branch users will have the ability to create a Schedule Hearing task for the appeal as long as 1) The appeal does not already have a hearing with no disposition, and 2) The appeal does not already have an open Schedule Hearing task. When a user begins working on the Schedule Hearing task, a modal is displayed. This modal will display a noneditable hearing location (Central Office or the RO for a video hearing) and dropdown of upcoming hearing dates with available slots for that hearing location. If the user has navigated to the Case Details page from the Assign Hearings page, the hearing date will be prepopulated with the date the user selected on the Assign Hearings page. If the user has navigated to the Case Details page a different way, the date will not be prepopulated. diff --git a/docs/tech-specs/2018-11-16-co-parent-records-transition.md b/docs/tech-specs/2018-11-16-co-parent-records-transition.md index f173a4d07aa..b831702044b 100644 --- a/docs/tech-specs/2018-11-16-co-parent-records-transition.md +++ b/docs/tech-specs/2018-11-16-co-parent-records-transition.md @@ -1,11 +1,11 @@ -This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/master/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Tech%20Specs/COParentRecordsTransition.md). +This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/main/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Tech%20Specs/COParentRecordsTransition.md). -## CO Parent Records to Caseflow +## CO Parent Records to Caseflow -Owner: Sharon Warner +Owner: Sharon Warner Date: 2018-11-16 -Reviewer(s): Oscar Ramirez, Meredith Stewart, & Andrew Lomax -Review by: 2018-11-18 +Reviewer(s): Oscar Ramirez, Meredith Stewart, & Andrew Lomax +Review by: 2018-11-18 ## Context diff --git a/docs/tech-specs/2018-11-28-legacy-issue-establishment.md b/docs/tech-specs/2018-11-28-legacy-issue-establishment.md index 3eabcaf036d..f1adcc74693 100644 --- a/docs/tech-specs/2018-11-28-legacy-issue-establishment.md +++ b/docs/tech-specs/2018-11-28-legacy-issue-establishment.md @@ -1,4 +1,4 @@ -This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/master/Project%20Folders/Caseflow%20Projects/Intake/Tech%20Specs/legacy-issue-establishment.md). +This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/main/Project%20Folders/Caseflow%20Projects/Intake/Tech%20Specs/legacy-issue-establishment.md). # Legacy Issue Optin @@ -37,9 +37,9 @@ Example schema: -------------------------------+-----------------------------+-----------+------------------------------- id | bigint | not null | autoincrement request_issue_id | bigint | not null | - submitted_at | timestamp without time zone | | - attempted_at | timestamp without time zone | | - processed_at | timestamp without time zone | | + submitted_at | timestamp without time zone | | + attempted_at | timestamp without time zone | | + processed_at | timestamp without time zone | | error | character varying | | ``` diff --git a/docs/tech-specs/2018-11-30-alternate-hearing-locations.md b/docs/tech-specs/2018-11-30-alternate-hearing-locations.md index 9df595e4af0..257c277de8d 100644 --- a/docs/tech-specs/2018-11-30-alternate-hearing-locations.md +++ b/docs/tech-specs/2018-11-30-alternate-hearing-locations.md @@ -1,10 +1,10 @@ -This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/master/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Tech%20Specs/AlternateHearingLocations.md). +This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/main/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Tech%20Specs/AlternateHearingLocations.md). ## Alternate Hearing Locations -Owner: Andrew Lomax -Date: 2018-11-30 -Reviewer(s): Sharon Warner +Owner: Andrew Lomax +Date: 2018-11-30 +Reviewer(s): Sharon Warner Review by: 2018-11-30 ## Context @@ -17,7 +17,7 @@ We have compiled a list of all alternate hearing locations for each RO and need - Assign Hearings page ## Overview -[Research](https://github.com/department-of-veterans-affairs/caseflow/issues/7507) +[Research](https://github.com/department-of-veterans-affairs/caseflow/issues/7507) [Facility Locator API](https://github.com/department-of-veterans-affairs/caseflow/issues/7545) #### Necessary data diff --git a/docs/tech-specs/2018-12-06-legacy-issue-optin-and-rollback.md b/docs/tech-specs/2018-12-06-legacy-issue-optin-and-rollback.md index 4f764d86b51..e18b7a79611 100644 --- a/docs/tech-specs/2018-12-06-legacy-issue-optin-and-rollback.md +++ b/docs/tech-specs/2018-12-06-legacy-issue-optin-and-rollback.md @@ -1,4 +1,4 @@ -This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/master/Project%20Folders/Caseflow%20Projects/Intake/Tech%20Specs/legacy-issue-optin-and-rollback.md). +This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/main/Project%20Folders/Caseflow%20Projects/Intake/Tech%20Specs/legacy-issue-optin-and-rollback.md). # Legacy issue opt-in and rollback @@ -25,7 +25,7 @@ This requires overwriting the existing disposition. We still need to determine how to approach remanded issues. Here are three proposals. ### 1 -Create a different follow up post-remand appeal for each issue closed (one appeal for each issue). Store which post-remand appeal gets created for each issue. +Create a different follow up post-remand appeal for each issue closed (one appeal for each issue). Store which post-remand appeal gets created for each issue. If all of the issues on the appeal are closed, close the appeal. This would mean that all of the issues on the appeal are closed, or if the issue has a disposition of "3", then it is associated with a post-remand appeal. diff --git a/docs/tech-specs/2019-01-28-hearing-task-flow.md b/docs/tech-specs/2019-01-28-hearing-task-flow.md index e3c3bfe7743..c02ddbcc86d 100644 --- a/docs/tech-specs/2019-01-28-hearing-task-flow.md +++ b/docs/tech-specs/2019-01-28-hearing-task-flow.md @@ -1,11 +1,11 @@ -This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/master/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Tech%20Specs/HearingTaskFlow.md). +This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/main/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Tech%20Specs/HearingTaskFlow.md). ## Hearing Task Flow -Owner: Sharon Warner -Date: 2019-01-28 -Reviewer(s): -Review by: +Owner: Sharon Warner +Date: 2019-01-28 +Reviewer(s): +Review by: ## Task Hierarchy ![](2019-01-28-hearing-task-flow.png) @@ -71,26 +71,26 @@ Review by: While most of the hearings associated tasks can be completed through the queue framework, the disposition task can only be completed through either the hearing prep daily docket or the hearing schedule daily docket. Because users may not understand the consequences of selecting dispositions on these pages, we will put safeguards in place to ensure we're not unnecessarily creating and deleting tasks. -***Disposition Job*** +***Disposition Job*** When a user marks a hearing as canceled, no show, or held, we will immediately save the disposition to the hearings table, but we will not take any task actions to move the appeal forward. The disposition will remain editable in the UI. We will create an overnight job to pull in all appeals with 1) open DispositionTasks that are not on hold, and 2) a hearing with a disposition that was not held that day (hearing coordinators and judges regularly update dispositions the day after a hearing was schedule). This job will perform the necessary actions described above to move appeals forward. -***Postponed Hearings*** +***Postponed Hearings*** When a user marks a hearing as postponed, we will both mark the hearing as postponed in the database and immediately create the necessary tasks to move the appeal forward. We are differentiating this case because postponing a hearing can require immediate action on the resulting tasks from the hearings management branch. -***UI*** +***UI*** The hearing prep and hearing schedule daily dockets will be updated such that the hearing dispositions are only editable if either 1) the appeal's DispositionTask is open and not on hold or 2) the appeal does not have a DispositionTask (legacy hearings scheduled prior to 2/1). We will also remove the autosave feature from the hearing prep daily docket and implement a save button. ## VACOLS Locations for Legacy Appeals -***Appeals in Location 57*** +***Appeals in Location 57*** We will run a job to continuously move appeals from location 57 to Caseflow. There should never be any appeal in location 57 that 1) has requested a video or CO hearing and 2) does not have an open hearing, for more than an hour. -***Appeals in Locations 36/38*** +***Appeals in Locations 36/38*** The hearings management branch will need to move appeals out of locations 36 and 38 as their associated hearings are held. We will no longer be putting appeals in these locations. -***Appeals in Location 'Caseflow'*** +***Appeals in Location 'Caseflow'*** We will add alerts in Looker to ensure that appeals do not get lost in Caseflow. The ticket for this is [here](https://github.com/department-of-veterans-affairs/caseflow/issues/8992). ## Open Questions diff --git a/docs/tech-specs/2019-04-11-hearing-prep-merge.md b/docs/tech-specs/2019-04-11-hearing-prep-merge.md index 2f37b48db0a..85bb75f47b3 100644 --- a/docs/tech-specs/2019-04-11-hearing-prep-merge.md +++ b/docs/tech-specs/2019-04-11-hearing-prep-merge.md @@ -1,15 +1,15 @@ -This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/master/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Tech%20Specs/HearingPrepMerge.md). +This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/main/Project%20Folders/Caseflow%20Projects/Hearings/Hearing%20Schedule/Tech%20Specs/HearingPrepMerge.md). ## Hearing Prep Merge -Owner: Sharon Warner -Date: 2019-04-11 -Reviewer(s): -Review by: +Owner: Sharon Warner +Date: 2019-04-11 +Reviewer(s): +Review by: ## Context -When Caseflow Hearing Prep was first developed 2 years ago, hearings' master records (records that group hearings by type, date, regional office, and judge) were stored in inconsistent ways in VACOLS. Video hearings were all linked to master records in the hearings table; CO hearings did not have any concept of master records; and travel board hearings had master records stored in a completely different table. Because these master records were so inconsistent, we determined it would be easier to not use master records within hearing prep and instead group hearings in our own way. +When Caseflow Hearing Prep was first developed 2 years ago, hearings' master records (records that group hearings by type, date, regional office, and judge) were stored in inconsistent ways in VACOLS. Video hearings were all linked to master records in the hearings table; CO hearings did not have any concept of master records; and travel board hearings had master records stored in a completely different table. Because these master records were so inconsistent, we determined it would be easier to not use master records within hearing prep and instead group hearings in our own way. Since Caseflow Hearing Schedule's rollout, however, we now have a consistent implementation of master records, now called hearing days, stored in caseflow's database. We also already have implemented hearing schedule views and daily dockets based on these hearing days. In order to minimize discrepancies between Hearing Prep and Hearing Schedule, we are merging Hearing Prep's hearing schedule views and daily dockets into Hearing Schedule. diff --git a/docs/tech-specs/2019-08-01-establish-930-corrections.md b/docs/tech-specs/2019-08-01-establish-930-corrections.md index 8168a6c29c8..68ef514587f 100644 --- a/docs/tech-specs/2019-08-01-establish-930-corrections.md +++ b/docs/tech-specs/2019-08-01-establish-930-corrections.md @@ -1,4 +1,4 @@ -This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/master/Project%20Folders/Caseflow%20Projects/Intake/Tech%20Specs/establish-930-corrections.md). +This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/main/Project%20Folders/Caseflow%20Projects/Intake/Tech%20Specs/establish-930-corrections.md). # Creating 930 corrections for request issues with decision issues **Notes:** diff --git a/docs/tech-specs/2019-10-10-integrating-caseflow-with-pexip.md b/docs/tech-specs/2019-10-10-integrating-caseflow-with-pexip.md index af789e0a6da..6a6d2ed20db 100644 --- a/docs/tech-specs/2019-10-10-integrating-caseflow-with-pexip.md +++ b/docs/tech-specs/2019-10-10-integrating-caseflow-with-pexip.md @@ -1,4 +1,4 @@ -This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/master/Project%20Folders/Caseflow%20Projects/Hearings/Telehearings/tech-specs/Integrating%20Caseflow%20with%20Pexip.md). +This document was moved from [appeals-team](https://github.com/department-of-veterans-affairs/appeals-team/blob/main/Project%20Folders/Caseflow%20Projects/Hearings/Telehearings/tech-specs/Integrating%20Caseflow%20with%20Pexip.md). # Integration with Pexip for Virtual Hearings @@ -15,7 +15,7 @@ There is an additional component to email the participants of the conference tha - [Epic](https://app.zenhub.com/workspaces/caseflow-5915dd178f67e20b5553ba0c/issues/department-of-veterans-affairs/caseflow/11132) - [Tech Spec](https://app.zenhub.com/workspace/o/department-of-veterans-affairs/caseflow/issues/12012) - [Implementation](https://app.zenhub.com/workspace/o/department-of-veterans-affairs/caseflow/issues/11730) - + ### Resources - [Pexip homepage](https://www.pexip.com) @@ -26,7 +26,7 @@ There is an additional component to email the participants of the conference tha - [Pexip browser support](https://docs.pexip.com/admin/interoperability.htm) - [Slack Thread on Deployment](https://dsva.slack.com/archives/CAM9FJ85P/p1570459327417500) - [Mapping Host to IP](https://github.com/department-of-veterans-affairs/appeals-deployment/blob/2b67911264124e41e887cf810f735c0d1eb8c493/ansible/vars/va-services.yml) - + ## Overview To support the BVA's video conferencing initiative, Caseflow will need to be able to manage Pexip conferences from creation to deletion using the Pexip API. @@ -348,7 +348,7 @@ Where: The URL must always include `https://

/webapp/?` But the remainder of the fields are optional. If a field is not specified in the URL, the user joining the conference will be asked to fill in the appropriate fields in a form before joining the conference. -We can pre-fill some or all of these fields and allow participants the participants to review and make changes before joining or we can format the URL so that the participants are taken straight into the conference. The latter is preferable as we will display a link on the hearing docket for judges and send emails containing the URL with detailed instructions to all participants. +We can pre-fill some or all of these fields and allow participants the participants to review and make changes before joining or we can format the URL so that the participants are taken straight into the conference. The latter is preferable as we will display a link on the hearing docket for judges and send emails containing the URL with detailed instructions to all participants. ### Deleting Conferences for Past Hearings diff --git a/docs/tech-specs/README.md b/docs/tech-specs/README.md index 3d9efc8e903..cad1a687571 100644 --- a/docs/tech-specs/README.md +++ b/docs/tech-specs/README.md @@ -17,8 +17,8 @@ This folder contains tech specs for the Caseflow team. ## In order to write a tech spec and get it reviewed do the following: 1. Clone this repo -2. Start drafting a tech spec by opening a PR creating a file titled YYYY-MM-DD-(tech-spec-name).md in this folder with your tech spec. You can use the [tech spec template here](https://github.com/department-of-veterans-affairs/caseflow/blob/master/.github/ISSUE_TEMPLATE/tech-spec.md) +2. Start drafting a tech spec by opening a PR creating a file titled YYYY-MM-DD-(tech-spec-name).md in this folder with your tech spec. You can use the [tech spec template here](https://github.com/department-of-veterans-affairs/caseflow/blob/main/.github/ISSUE_TEMPLATE/tech-spec.md) 3. Post in #appeals-development and request for others to review the tech spec 4. Schedule time on the VA Appeals calendar with your scrum team or the whole Caseflow engineering team as appropriate to discuss the tech spec -5. Once comments are addressed, the tech spec is finalized and your PR is approved, merge your commit to master so that the tech spec is preserved for future team mates +5. Once comments are addressed, the tech spec is finalized and your PR is approved, merge your commit to main so that the tech spec is preserved for future team mates 6. Link your tech spec in future PRs that implement the changes diff --git a/scripts/dev_env_setup_step1.sh b/scripts/dev_env_setup_step1.sh index e29b26b96da..d49852d6f45 100755 --- a/scripts/dev_env_setup_step1.sh +++ b/scripts/dev_env_setup_step1.sh @@ -1,7 +1,7 @@ #!/bin/bash # This script automates the Developer Setup described here: -# https://github.com/department-of-veterans-affairs/caseflow/blob/master/README.md#developer-setup +# https://github.com/department-of-veterans-affairs/caseflow/blob/main/README.md#developer-setup # It is okay to run this script multiple times. # Only Mac has been tested. diff --git a/scripts/dev_env_setup_step2.sh b/scripts/dev_env_setup_step2.sh index 7df7a9dab77..d8698878fb2 100755 --- a/scripts/dev_env_setup_step2.sh +++ b/scripts/dev_env_setup_step2.sh @@ -1,7 +1,7 @@ #!/bin/bash # Continuation of Developer Setup at -# https://github.com/department-of-veterans-affairs/caseflow/blob/master/README.md#install-ruby-dependencies +# https://github.com/department-of-veterans-affairs/caseflow/blob/main/README.md#install-ruby-dependencies function detectVersion(){ # https://stackoverflow.com/questions/3466166/how-to-check-if-running-in-cygwin-mac-or-linux @@ -50,5 +50,5 @@ Congratulations " echo 'Finish the manual set up from "Database environment setup": - https://github.com/department-of-veterans-affairs/caseflow/blob/master/README.md#database-environment-setup + https://github.com/department-of-veterans-affairs/caseflow/blob/main/README.md#database-environment-setup ' diff --git a/scripts/whats-next b/scripts/whats-next index ac930ab72e3..e3532c4cbef 100755 --- a/scripts/whats-next +++ b/scripts/whats-next @@ -1,4 +1,4 @@ #!/bin/sh LATEST_DEPLOY_TAG=`git tag --list 'deployed/*' | sort -r | head -1` -git log --pretty=format:"%h%x09%an%x09%x09%s" $LATEST_DEPLOY_TAG...master +git log --pretty=format:"%h%x09%an%x09%x09%s" $LATEST_DEPLOY_TAG...main diff --git a/spec/rails_helper.rb b/spec/rails_helper.rb index 42fef233216..4521dd0a544 100644 --- a/spec/rails_helper.rb +++ b/spec/rails_helper.rb @@ -102,7 +102,7 @@ end # Wrap this around your test to run it many times and ensure that it passes consistently. -# Note: do not merge to master like this, or the tests will be slow! Ha. +# Note: do not merge to main like this, or the tests will be slow! Ha. def ensure_stable repeat_count = ENV.fetch("ENSURE_STABLE", "10").to_i repeat_count.times do