From faa1df8d9bb9e95715c971390a848daa375b1ccd Mon Sep 17 00:00:00 2001 From: samglover Date: Tue, 12 Nov 2024 15:06:49 -0600 Subject: [PATCH 01/14] Un-awkward a sentence in the intro paragraph --- docs/get_started/roadmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/get_started/roadmap.md b/docs/get_started/roadmap.md index f6e4714b9..85ec9ebf4 100644 --- a/docs/get_started/roadmap.md +++ b/docs/get_started/roadmap.md @@ -5,7 +5,7 @@ sidebar_label: Roadmap slug: /get_started/roadmap --- -Whether you are a LIT Clinic student, a recent [Forms Camp](https://www.ncsc.org/consulting-and-research/areas-of-expertise/access-to-justice/forms-camp) graduate, or anyone else getting started on an interview-building project—whether it is your first or fiftieth—this page will guide you through the stages of a successful project, from concept to launch. +Whether you are a LIT Clinic student, a recent [Forms Camp](https://www.ncsc.org/consulting-and-research/areas-of-expertise/access-to-justice/forms-camp) graduate, or anyone else getting started on an interview-building project, this page will guide you through the stages of a successful project. This roadmap reflects the procedures, templates, and tools the LIT Lab uses on our own interview-building projects, which you can adapt to your projects. From 9d894c5cbe6b7e58766c161620aec39a9eeb10b0 Mon Sep 17 00:00:00 2001 From: samglover Date: Tue, 12 Nov 2024 15:07:22 -0600 Subject: [PATCH 02/14] Link to the MVP skateboard analogy source --- docs/get_started/roadmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/get_started/roadmap.md b/docs/get_started/roadmap.md index 85ec9ebf4..cda92de32 100644 --- a/docs/get_started/roadmap.md +++ b/docs/get_started/roadmap.md @@ -77,7 +77,7 @@ Here is a sample kickoff meeting agenda: ### Stick to an MVP A minimum viable product (MVP) is the essence of of iterative, incremental development—first make something that works, then make it better. -Consider Henrik Kniberg's skateboard analogy: +Consider [Henrik Kniberg's skateboard analogy](https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp): ![Minimum viable product](../assets/mvp.png) From 4bc8c5f72532462879460d4738ffe89d5f7be3e9 Mon Sep 17 00:00:00 2001 From: samglover Date: Tue, 12 Nov 2024 15:09:00 -0600 Subject: [PATCH 03/14] Change MVP advice language --- docs/get_started/roadmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/get_started/roadmap.md b/docs/get_started/roadmap.md index cda92de32..75e41e469 100644 --- a/docs/get_started/roadmap.md +++ b/docs/get_started/roadmap.md @@ -81,7 +81,7 @@ Consider [Henrik Kniberg's skateboard analogy](https://blog.crisp.se/2016/01/25/ ![Minimum viable product](../assets/mvp.png) -Different projects will have different MVPs/"skateboards". The [legal form maturity model](https://suffolklitlab.org/legal-tech-class/docs/legal-tech-overview/maturity-model/#quick-summary) can help you identify the MVP for your project (interviews built for the general public should usually target level 2+). Once you decide what this project's MVP is, avoid adding anything more to it. +Different projects will have different MVPs/"skateboards". The [legal form maturity model](https://suffolklitlab.org/legal-tech-class/docs/legal-tech-overview/maturity-model/#quick-summary) can help you identify the MVP for your project (interviews built for the general public should usually target level 2+). Once you decide what this project's MVP is, stick to it. Don't add to the MVP without a compelling justification. ::: ## Complete the Draft Interview From 942f0a8d6b847a56da6926fc85f41b3024885bd6 Mon Sep 17 00:00:00 2001 From: samglover Date: Tue, 12 Nov 2024 15:15:40 -0600 Subject: [PATCH 04/14] Add preliminary feedback resources --- docs/get_started/roadmap.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/get_started/roadmap.md b/docs/get_started/roadmap.md index 75e41e469..9deeb24a8 100644 --- a/docs/get_started/roadmap.md +++ b/docs/get_started/roadmap.md @@ -151,6 +151,10 @@ For complex interviews that involve multiple forms/templates, consider doing thi Before you show the interview to the decisionmaker and stakeholders, get someone with Document Assembly Line experience to test it with you. This will help you identify issues you may have missed and questions you still need to ask the decisionmaker. +:::tip +If you aren't sure where to find someone to give you preliminary feedback, try asking [the community](http://localhost:3000/docs/get_started#join-the-community)! Come to one of the Monday community meetings or ask in the Microsoft Teams forum. +::: + To get the interview ready: 1. [Merge your code](../github#create-a-pull-request) into **main** or a testing branch From ace1c2826ba7c5dcaa92a8802975c2768715f03a Mon Sep 17 00:00:00 2001 From: samglover Date: Tue, 12 Nov 2024 15:18:42 -0600 Subject: [PATCH 05/14] Remove unnecessary details related to preparing for feedback --- docs/get_started/roadmap.md | 16 ++-------------- 1 file changed, 2 insertions(+), 14 deletions(-) diff --git a/docs/get_started/roadmap.md b/docs/get_started/roadmap.md index 9deeb24a8..959a32bd4 100644 --- a/docs/get_started/roadmap.md +++ b/docs/get_started/roadmap.md @@ -155,13 +155,7 @@ Before you show the interview to the decisionmaker and stakeholders, get someone If you aren't sure where to find someone to give you preliminary feedback, try asking [the community](http://localhost:3000/docs/get_started#join-the-community)! Come to one of the Monday community meetings or ask in the Microsoft Teams forum. ::: -To get the interview ready: - -1. [Merge your code](../github#create-a-pull-request) into **main** or a testing branch -2. [Create a new playground project](../github#create-and-manage-playground-projects) for the interview demonstration and pull your code into it -3. Make sure the interview works as expected in the testing project - -Once the interview is ready, schedule a video meeting with the tester so you can watch them go through the interview. Or they can watch you demonstrate it. Record the test if you can so you can focus on the test instead of taking notes. +Schedule a video meeting with the tester so you can watch them go through the interview. Or they can watch you demonstrate it. Record the test if you can so you can focus on the test instead of taking notes. During the demonstration or testing: @@ -173,13 +167,7 @@ During the demonstration or testing: Once you have closed all the issues that are in scope for the [MVP](#stick-to-an-mvp) and tested the interview yourself, it should be ready to hand off to the decisionmaker and stakeholders for their testing and feedback. -Get the interview ready the same as [above](#preliminary-feedback), then click the **Share** button in the testing project playground to get the link to the interview. - -:::tip -When sharing the interview link, make sure the URL ends with `#page1`. If you have been testing the interview the **Share** link will point to the last page you were viewing instead of the start of the interview. Usually this won't matter, but it could result in unexpected behavior. -::: - -Share the link with the decisionmaker and give them a few tips for giving helpful feedback: +Share the interview with the decisionmaker and give them a few tips for giving helpful feedback: * The feedback should come in the form of a written list of requested changes * If there is confusing or conflicting feedback from stakeholders it is the decisionmaker's responsiblity to clarify it before presenting it to the interview building team From 239866d786f827d6f44178f7157112899389148f Mon Sep 17 00:00:00 2001 From: samglover Date: Tue, 12 Nov 2024 15:21:04 -0600 Subject: [PATCH 06/14] Simplify feedback tips regarding interview ID/page number --- docs/get_started/roadmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/get_started/roadmap.md b/docs/get_started/roadmap.md index 959a32bd4..56a81df48 100644 --- a/docs/get_started/roadmap.md +++ b/docs/get_started/roadmap.md @@ -172,7 +172,7 @@ Share the interview with the decisionmaker and give them a few tips for giving h * The feedback should come in the form of a written list of requested changes * If there is confusing or conflicting feedback from stakeholders it is the decisionmaker's responsiblity to clarify it before presenting it to the interview building team * Change requests should be specific. For example, if the text of a question should be changed, the change request should include the new text. -* At the top of each page of the interview is an ID. This ID is a reliable identifier when referring to an interview page. (For example, the "fifth page" might be different depending on the interview logic.) +* At the top of each page of the interview is an ID. Use the ID to refer to specific interview pages, not a page number. ## Revise the Interview From 913d6258b2400922c052cb1b6e19c0a3a0f664e2 Mon Sep 17 00:00:00 2001 From: samglover Date: Tue, 12 Nov 2024 15:23:05 -0600 Subject: [PATCH 07/14] Simplify information about rounds of revision --- docs/get_started/roadmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/get_started/roadmap.md b/docs/get_started/roadmap.md index 56a81df48..2fe1766b1 100644 --- a/docs/get_started/roadmap.md +++ b/docs/get_started/roadmap.md @@ -181,7 +181,7 @@ After getting feedback, create a [GitHub issue](../github#use-issues) for each c When you have closed all the issues/items on your punch list, send it back to the decisionmaker for further feedback. Each round of feedback should result in fewer change requests and move the project closer to completion. :::info -Two rounds of feedback and revision are usually enough. It it takes more than three, consider ways to improve your process going forward. +Two rounds of feedback and revision are usually enough. ::: ## Get a Go/No-Go Decision From 882c8b9536c5f4ada75a77a52e3728a5be011d6d Mon Sep 17 00:00:00 2001 From: samglover Date: Tue, 12 Nov 2024 15:25:37 -0600 Subject: [PATCH 08/14] Recommend a retrospective for interview project failures --- docs/get_started/roadmap.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/get_started/roadmap.md b/docs/get_started/roadmap.md index 2fe1766b1..b0a2a5ada 100644 --- a/docs/get_started/roadmap.md +++ b/docs/get_started/roadmap.md @@ -208,6 +208,8 @@ You can also set up [collect analytics](../analytics/tracking_usage) to learn ho Before you start another interview-building project, pause briefly for a retrospective on how this one went. The retrospective format comes from [Agile software development](https://en.wikipedia.org/wiki/Agile_software_development), and it is a way to embrace continuous improvement by taking a moment to reflect on the project you just finished in order to improve the next one. +If your interview project fails, a retrospective is an important tool for making sure you avoid another failure. + To do a retrospective, gather the group and discuss three questions: 1. What went well that we should keep doing? From ac27b56e4446ef395630dc5bbe7a0a7a2b36ed14 Mon Sep 17 00:00:00 2001 From: samglover Date: Tue, 12 Nov 2024 15:26:50 -0600 Subject: [PATCH 09/14] Add promotion to the kickoff meeting checklist --- docs/get_started/roadmap.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/get_started/roadmap.md b/docs/get_started/roadmap.md index b0a2a5ada..57d22b097 100644 --- a/docs/get_started/roadmap.md +++ b/docs/get_started/roadmap.md @@ -70,6 +70,7 @@ Here is a sample kickoff meeting agenda: * Decisionmaker/stakeholder feedback * Interview finalized and ready for go/no-go decision * Launch + * Promotion * Discuss what success looks like for this project, and how you will measure it * Consider doing a [pre-mortem](https://en.wikipedia.org/wiki/Pre-mortem)—imagine this project has failed and discuss why From 74e809199f3938a6ae5a92d153a83f8fa75070dd Mon Sep 17 00:00:00 2001 From: samglover Date: Tue, 12 Nov 2024 15:30:23 -0600 Subject: [PATCH 10/14] Clarify tips on retrospectives --- docs/get_started/roadmap.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/get_started/roadmap.md b/docs/get_started/roadmap.md index 57d22b097..6c581cc1b 100644 --- a/docs/get_started/roadmap.md +++ b/docs/get_started/roadmap.md @@ -211,13 +211,13 @@ Before you start another interview-building project, pause briefly for a retrosp If your interview project fails, a retrospective is an important tool for making sure you avoid another failure. -To do a retrospective, gather the group and discuss three questions: +To do a retrospective, the project manager should meet with each member of the group to discuss and document the answers to three questions: 1. What went well that we should keep doing? 2. What did not go well that we should stop doing? 3. What should we try going forward? -Retrospectives are generally more effective when the team is together in real time—on Zoom, for example. Depending on the group dynamics you can do a retrospective as a group or meet with one person at a time. +Retrospectives are generally most effective one-on-one, in real time. :::tip Insist that everyone give at least one answer to each question. Even if someone insists nothing went badly, ask if they found themselves confused or struggling at any point during the project. Their answer may lead to an area that could be improved. From 89c8f631a47659b8293412c328d0a40af7e59947 Mon Sep 17 00:00:00 2001 From: samglover Date: Tue, 12 Nov 2024 15:34:46 -0600 Subject: [PATCH 11/14] Add DAL workshop videos --- docs/get_started/roadmap.md | 10 +++++++++- docs/github.md | 6 ++++++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/docs/get_started/roadmap.md b/docs/get_started/roadmap.md index 6c581cc1b..529dd695e 100644 --- a/docs/get_started/roadmap.md +++ b/docs/get_started/roadmap.md @@ -223,4 +223,12 @@ Retrospectives are generally most effective one-on-one, in real time. Insist that everyone give at least one answer to each question. Even if someone insists nothing went badly, ask if they found themselves confused or struggling at any point during the project. Their answer may lead to an area that could be improved. ::: -Use what you learn from the retrospective when planning your next interview-biulding project. \ No newline at end of file +Use what you learn from the retrospective when planning your next interview-biulding project. + +## Tips from the community + +In a Document Assembly Line workshop, members of the community shared their tips for managing a successful interview-building project: + +

+ +

\ No newline at end of file diff --git a/docs/github.md b/docs/github.md index 45a97a8d1..3a4c15b36 100644 --- a/docs/github.md +++ b/docs/github.md @@ -31,6 +31,12 @@ Here is what we recommend for a workflow for using GitHub with the Docassemble p 4. Once you have resolved any conflicts and any reviewers have signed off, merge the pull request and delete the branch. 5. Decide on the next task or issue you want to work on and start over at #1. +We also shared this workflow in a Document Assembly Line workshop: + +

+ +

+ :::warning When you pull a GitHub repository to a playground project, the files in the repository will overwrite any files with the same name in your project **without warning**. Create a new project, first, if you don't want to risk this. ::: From b669ff7225602f33069f2c91d336e6dacb562851 Mon Sep 17 00:00:00 2001 From: samglover Date: Tue, 12 Nov 2024 15:37:18 -0600 Subject: [PATCH 12/14] Change headings to sentence case --- docs/get_started/roadmap.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/get_started/roadmap.md b/docs/get_started/roadmap.md index 529dd695e..8504ed23e 100644 --- a/docs/get_started/roadmap.md +++ b/docs/get_started/roadmap.md @@ -1,6 +1,6 @@ --- id: roadmap -title: Roadmap of a Successful Interview Project +title: Roadmap of a successful interview project sidebar_label: Roadmap slug: /get_started/roadmap --- @@ -13,9 +13,9 @@ This roadmap reflects the procedures, templates, and tools the LIT Lab uses on o If this is your first interview-building project, it may help to read more about [planning and building your first expert system](https://projects.suffolklitlab.org/legal-tech-class/docs/interview-structure/building-an-app-outline). ::: -## Identify Key Roles & Responsibilities +## Identify key roles & responsibilities -![Interview Project Roles & Lines of Communication](../assets/interview-project-roles-communication.png) +![Interview project roles & lines of communication](../assets/interview-project-roles-communication.png) Every interview project has: @@ -27,7 +27,7 @@ Every interview project has: You may have a team of interview builders and dozens of stakeholders, or you may be the only person working on this project. Even if this is a solo project, it helps to keep your different roles in mind. ::: -### The Decisionmaker +### The decisionmaker **While a successful interview project needs all these roles, the decisionmaker is especially important.** Most interview projects involve multiple stakeholders. When the interview building team requests guidance or feedback, multiple stakeholders may give multiple responses that may be confusing or conflicting and dramatically slow progress. @@ -41,7 +41,7 @@ The decisionmaker's job is to gather and clarify stakeholders' feedback so that The decisionmaker must either (1) have the authority necessary to carry out these responsiblities, or (2) be responsible for getting authority when necessary. -## Kickoff Meeting +## Kickoff meeting Schedule a kickoff meeting for the project as early as possible. The interview building team, the decisionmaker, and the key stakeholders should attend. @@ -85,7 +85,7 @@ Consider [Henrik Kniberg's skateboard analogy](https://blog.crisp.se/2016/01/25/ Different projects will have different MVPs/"skateboards". The [legal form maturity model](https://suffolklitlab.org/legal-tech-class/docs/legal-tech-overview/maturity-model/#quick-summary) can help you identify the MVP for your project (interviews built for the general public should usually target level 2+). Once you decide what this project's MVP is, stick to it. Don't add to the MVP without a compelling justification. ::: -## Complete the Draft Interview +## Complete the draft interview After the kickoff meeting it is time to get to work! As you work on the interview, follow the [GitHub workflow](../github.md#workflow). If you get stuck on a problem for more than twenty minutes, ask for help. (Use the [Resources](resources.md) page to find options.) @@ -93,11 +93,11 @@ After the kickoff meeting it is time to get to work! As you work on the intervie The LIT Lab's [interview project template](https://github.com/orgs/SuffolkLITLab/projects/22) can help you keep your project organized and on track. Just click the **Use this template** button to use it. (You'll need a free [GitHub](../github.md) account.) ::: -## Meeting Cadence +## Meeting cadence Two recurring meetings will help you keep the project moving forward. These are short, 5–15 minute "standup" meetings to share progress and identify and remove blockers—anything preventing someone from making progress. -### Interview-Building Team Meetings +### Interview-building team meetings The interview-building team should meet frequently. Daily check-ins are common on active projects, and anything less than weekly is unlikely to be effective. @@ -115,7 +115,7 @@ The reason for sharing your progress and plan for the day or week is so that eve The reason for sharing blockers is to get help. Some teams reserve a larger block of time and use it to solve blockers together, like we do in our Monday community meetings. Other teams prefer to solve blockers separately. And sometimes a blocker is a question you need answered by the decisionmaker. -### Decisionmaker Meetings +### Decisionmaker meetings Weekly or every-other week meetings with the decisionmaker and one or two key stakeholders are a chance to keep them informed of your progress and get decisions when you need them to move forward. The standing agenda is similar to the one above: @@ -140,7 +140,7 @@ To get better answers, ask questions better. Here are some tips for asking quest Finally, when showing the relevant part of the interview as part of asking a question, remind the decisionmaker and stakeholders that the interview is a work in progress and you are not ready for feedback beyond the answer to your question. -## Get Feedback on the Interview +## Get feedback on the interview Once the interview works from start to finish and you have closed all the issues that are in scope for the [MVP](#stick-to-an-mvp), it is ready for feedback. Start by getting preliminary feedback from someone with Document Assembly Line experience. After you have made revisions based on the preliminary feedback, give the interview to the decisionmaker and stakeholders for their feedback. @@ -148,7 +148,7 @@ Once the interview works from start to finish and you have closed all the issues For complex interviews that involve multiple forms/templates, consider doing this in stages. Start with the simplest form and get preliminary and stakeholder feedback early. Then move on to the most complex form to confirm the shape and logic of the overall interview. Then continue with the remaining forms. ::: -### Preliminary Feedback +### Preliminary feedback Before you show the interview to the decisionmaker and stakeholders, get someone with Document Assembly Line experience to test it with you. This will help you identify issues you may have missed and questions you still need to ask the decisionmaker. @@ -164,7 +164,7 @@ During the demonstration or testing: * Ask them to follow different branches of the interview logic * Listen carefully to their feedback and ask follow-up questions to make sure you understand it -### Stakeholder Feedback +### Stakeholder feedback Once you have closed all the issues that are in scope for the [MVP](#stick-to-an-mvp) and tested the interview yourself, it should be ready to hand off to the decisionmaker and stakeholders for their testing and feedback. @@ -175,7 +175,7 @@ Share the interview with the decisionmaker and give them a few tips for giving h * Change requests should be specific. For example, if the text of a question should be changed, the change request should include the new text. * At the top of each page of the interview is an ID. Use the ID to refer to specific interview pages, not a page number. -## Revise the Interview +## Revise the interview After getting feedback, create a [GitHub issue](../github#use-issues) for each change request from the tester or decisionmaker. Consider this your "punch list" to finish the project. Then get back to work on those issues! @@ -185,7 +185,7 @@ When you have closed all the issues/items on your punch list, send it back to th Two rounds of feedback and revision are usually enough. ::: -## Get a Go/No-Go Decision +## Get a go/no-go decision When the interview is complete, there is one last decision for the decisionmaker to make: whether the interview is ready to go live. @@ -193,7 +193,7 @@ If the answer is yes, launch the interview! If the answer is no, find out if further revision would result in a yes. If not, [do a retrospective](#do-a-retrospective) and try to understand what happened. -## Launch the Interview +## Launch the interview When you are ready to launch, add the interview to your production server and make sure it works as intended. @@ -205,7 +205,7 @@ Once the interview is live, consider how people who need it will find it. You can also set up [collect analytics](../analytics/tracking_usage) to learn how people are finding and using the interview. -## Do a Retrospective +## Do a retrospective Before you start another interview-building project, pause briefly for a retrospective on how this one went. The retrospective format comes from [Agile software development](https://en.wikipedia.org/wiki/Agile_software_development), and it is a way to embrace continuous improvement by taking a moment to reflect on the project you just finished in order to improve the next one. From 2d1f5ae763158d1a6e2bb41b2921624a082e50ec Mon Sep 17 00:00:00 2001 From: samglover Date: Tue, 12 Nov 2024 15:48:53 -0600 Subject: [PATCH 13/14] Rename the roadmap page to project management guide to avoid confusion with the development roadmap --- docs/get_started/beginners_guide.md | 8 ++++---- docs/get_started/intro.md | 2 +- .../{roadmap.md => project_management.md} | 8 ++++---- docusaurus.config.js | 16 ++++++++++------ sidebars.js | 2 +- 5 files changed, 20 insertions(+), 16 deletions(-) rename docs/get_started/{roadmap.md => project_management.md} (99%) diff --git a/docs/get_started/beginners_guide.md b/docs/get_started/beginners_guide.md index 7733e5014..3e0950d08 100644 --- a/docs/get_started/beginners_guide.md +++ b/docs/get_started/beginners_guide.md @@ -13,7 +13,7 @@ Here are the steps: 1. [Do the Hello, World exercise](#do-the-hello-world-exercise) for a friendly introduction to Docassemble 2. [Watch a demonstration of the Weaver](#watch-a-demonstration-of-the-weaver), a Document Assembly Line tool for quickly turning prepared forms into draft Docassemble interviews -3. [Review the interview project roadmap](#review-the-interview-project-roadmap) +3. [Review the interview project management page](#review-the-interview-project-management-guide) 4. [Join the Document Assembly Line community](#join-the-document-assembly-line-community) 5. [Start building your first interview!](#start-building-your-first-interview) @@ -43,11 +43,11 @@ The interview generated by the Weaver is not a finished interview. It is a start Now you are probably itching to start building your first interview! But before you do, take a moment to review the interview-building workflow and join the Document Assembly Line community. -## Review the Interview Project Roadmap +## Review the Interview Project Management Guide Building a successful interview involves more than just coding in the Docassemble playground. You'll also need to consider things like project management, [working with a team](working_with_teams.md), [requirements](working_with_teams.md#understanding-the-projects-users-and-intended-purpose), [usability](../question_style_overview.md), [testing](/alkiln/intro.mdx), etc. -**➡️ [Review the interview-building workflow.](roadmap.md)** +**➡️ [Review the interview project management guide.](project_management.md)** ## Join the Document Assembly Line Community @@ -59,7 +59,7 @@ You can also take advantage of other [interview building resources and documenta ## Start Building Your First Interview! -You probably already have an idea of the first form you want to work on, so pull up the [workflow](roadmap.md) and get started! +You probably already have an idea of the first form you want to work on, so pull up the [project management guide](project_management.md) and get started! ## Learn More diff --git a/docs/get_started/intro.md b/docs/get_started/intro.md index 6e39b5618..4f9f2fe7a 100644 --- a/docs/get_started/intro.md +++ b/docs/get_started/intro.md @@ -17,7 +17,7 @@ This short, 3-minute video by David Colarusso and Quinten Steenhuis explains how The LIT Lab gathered more than 200 volunteers from around the world and built tools such as: -* An [workflow](/get_started/roadmap.md) for building [Docassemble](https://docassemble.org) interviews to assemble court forms for filing. +* A [project management guide](/get_started/project_management.md) for building [Docassemble](https://docassemble.org) interviews to assemble court forms for filing. * The core [Document Assembly Line Tools](https://github.com/SuffolkLITLab/docassemble-AssemblyLine), to make it easier to use key Docassemble features. * The [the Weaver](generating_code), a tool for converting existing PDF and DOCX court forms into draft Docassemble interviews in as little as one hour. * A [library](question_library/names) of pre-built, commonly used, accessible questions, vetted by experts and translated into at least 5 languages. diff --git a/docs/get_started/roadmap.md b/docs/get_started/project_management.md similarity index 99% rename from docs/get_started/roadmap.md rename to docs/get_started/project_management.md index 8504ed23e..cee088870 100644 --- a/docs/get_started/roadmap.md +++ b/docs/get_started/project_management.md @@ -1,8 +1,8 @@ --- -id: roadmap -title: Roadmap of a successful interview project -sidebar_label: Roadmap -slug: /get_started/roadmap +id: project_management +title: Interview project management guide +sidebar_label: Project management +slug: /get_started/project_management --- Whether you are a LIT Clinic student, a recent [Forms Camp](https://www.ncsc.org/consulting-and-research/areas-of-expertise/access-to-justice/forms-camp) graduate, or anyone else getting started on an interview-building project, this page will guide you through the stages of a successful project. diff --git a/docusaurus.config.js b/docusaurus.config.js index 1fbe36a67..ea915f0da 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -100,17 +100,21 @@ module.exports = { from: '/docs/installation', to: '/docs/get_started/installation' }, + { + from: '/docs/get_started/roadmap', + to: '/docs/get_started/project_management' + }, { from: '/docs/assembly_line_steps', - to: '/docs/get_started/roadmap' + to: '/docs/get_started/project_management' }, { from: '/docs/assembly_line_steps/roles', - to: '/docs/get_started/roadmap#identify-key-roles--responsibilities' + to: '/docs/get_started/project_management#identify-key-roles--responsibilities' }, { from: '/docs/assembly_line_steps/steps', - to: '/docs/get_started/roadmap' + to: '/docs/get_started/project_management' }, { from: '/docs/bootcamp', @@ -118,15 +122,15 @@ module.exports = { }, { from: '/docs/get_started/assembly_line_steps/roles', - to: '/docs/get_started/roadmap#identify-key-roles--responsibilities' + to: '/docs/get_started/project_management#identify-key-roles--responsibilities' }, { from: '/docs/get_started/assembly_line_steps', - to: '/docs/get_started/roadmap' + to: '/docs/get_started/project_management' }, { from: '/docs/get_started/assembly_line_steps/steps', - to: '/docs/get_started/roadmap' + to: '/docs/get_started/project_management' }, { from: '/docs/planning', diff --git a/sidebars.js b/sidebars.js index 8bed4452e..2c2a2b19f 100644 --- a/sidebars.js +++ b/sidebars.js @@ -10,7 +10,7 @@ module.exports = { type: 'category', label: 'Interview Projects', items: [ - 'get_started/roadmap', + 'get_started/project_management', 'get_started/working_with_teams', ], collapsed: false, From 085e06ccec597f4ef08ec07ca7ccb503dde8e0c6 Mon Sep 17 00:00:00 2001 From: samglover Date: Tue, 12 Nov 2024 15:50:28 -0600 Subject: [PATCH 14/14] Change headings to sentence case --- docs/get_started/beginners_guide.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/get_started/beginners_guide.md b/docs/get_started/beginners_guide.md index 3e0950d08..4b182c5f1 100644 --- a/docs/get_started/beginners_guide.md +++ b/docs/get_started/beginners_guide.md @@ -1,7 +1,7 @@ --- id: beginners_guide -title: Learn to Build Docassemble Interviews -sidebar_label: Beginner's Guide +title: Learn to build Docassemble interviews +sidebar_label: Beginner's guide slug: /get_started/beginners_guide --- @@ -21,7 +21,7 @@ Here are the steps: In order to build interviews you will need access to a [Docassemble playground](https://docassemble.org/docs/playground.html). But if you don't have one you can use ours! Register an account on the [LIT Lab Docassemble development server](https://apps-dev.suffolklitlab.org/user/register), then [email us](mailto:litlab@suffolk.edu) and ask for developer privileges. ::: -## Do the Hello, World Exercise +## Do the Hello, World exercise In his Legal Tech Class, Quinten Steenhuis introduces Docassemble with a [short "Hello, World" exercise](https://suffolklitlab.org/legal-tech-class/docs/classes/docacon-2020/hello-world). This introductory exercise is a great way to demystify Docassemble and see what it's like to build a simple interview—by actually doing it. @@ -31,7 +31,7 @@ Once you have successfully completed the Hello, World exercise you might want to When you have finished the Hello, World exercise, move on to the next step: learning about the Weaver. -## Watch a Demonstration of the Weaver +## Watch a demonstration of the Weaver The Weaver is a Document Assembly Line tool that generates a draft Docassemble interview from a prepared PDF or DOCX form so you don't have to start from scratch. The best way to explain it is to see it in action: @@ -43,13 +43,13 @@ The interview generated by the Weaver is not a finished interview. It is a start Now you are probably itching to start building your first interview! But before you do, take a moment to review the interview-building workflow and join the Document Assembly Line community. -## Review the Interview Project Management Guide +## Review the interview project management guide Building a successful interview involves more than just coding in the Docassemble playground. You'll also need to consider things like project management, [working with a team](working_with_teams.md), [requirements](working_with_teams.md#understanding-the-projects-users-and-intended-purpose), [usability](../question_style_overview.md), [testing](/alkiln/intro.mdx), etc. **➡️ [Review the interview project management guide.](project_management.md)** -## Join the Document Assembly Line Community +## Join the Document Assembly Line community You know enough to get started, but you will need help. The Document Assembly Line community meets weekly on Zoom for live support, and coding help is available 24/7 in our Microsoft Teams forum. @@ -57,11 +57,11 @@ You know enough to get started, but you will need help. The Document Assembly Li You can also take advantage of other [interview building resources and documentation](resources.md). -## Start Building Your First Interview! +## Start building your first interview! You probably already have an idea of the first form you want to work on, so pull up the [project management guide](project_management.md) and get started! -## Learn More +## Learn more If you've completed the above you are ready to get started building your first interview. But if you want a more in-depth beginner training, check out this 3.5–hour beginner training from [Docacon 2020](https://docacon.com/2020/index.html):