Skip to content

roadmap.md

Latest commit

 

History

History
128 lines (96 loc) · 33 KB

roadmap.md

File metadata and controls

128 lines (96 loc) · 33 KB
Raw

Roadmap

Where the project stands: the team's working list. Update this page whenever something finishes or a new need comes up. For the community-facing list of planned work, see Planned work; keep the two in step when an item starts or finishes.

Done

  • The design spec and the knowledge framework.

  • Calibration scripts (parts 1 to 4) that run inside Rock's SQL editor, the normalizer, and profile v1.

  • The church setup as data: 7 campuses, Sunday service times, funds with campus accounts, check-in rooms, and connection statuses.

  • The Cast: 38 legacy families converted, plus 62 new families and 4 new businesses, for 104 households and 230 people. Featured families have a bio for each person, and every family has a page.

  • The address pool: 18,000 real-street addresses with house numbers that do not exist, and the Cast moved onto it.

  • The Phase 0 builder: configuration, people, Sunday attendance and kids check-in, giving history, a generated crowd, and validation. Core 1 loads in about 4 seconds. Full 7 with a 17,000-household crowd loads in about 29 seconds (about 44 with check images) and passes 89% of measured values.

  • Photo rules, photo ethnicity for every Cast adult, and the image agent's brief.

  • The public site's church page has an Initiatives section: Starting Point, the first, with its artwork, and the Built on the Rock campaign. The brand page offers initiative artwork as downloads. On phones, the top navigation folds behind a Menu button.

  • Seven distinct campus exterior photos, ready for Sunday morning without people. Goodyear meets in a high school auditorium and sets up and tears down every Sunday, Scottsdale keeps the traditional church building it had as an independent church before it merged, and Phoenix follows the existing building references. The public site's campus cards and downloads include the set (decision 135). Campus image loading into Rock remains separate work.

  • One building fund. Rock's Building Fund is now the Built on the Rock campaign fund, and the separate campaign fund is gone. Building upkeep comes from the General Fund, so givers who gave to the Building Fund give the same amount there (decisions 98 and 99).

  • All 45 legacy Cast portraits have been updated and approved. The temporary photo review is closed.

  • Every Cast photo is delivered: 130 new people, the 45 legacy redos, and 36 staff and staff family members (211 photos), plus the 120-photo Core 3 pool. All are in photos/manifest.json.

  • Photos load into Rock: every Cast person's delivered photo shows on their profile, and in Core 3 about half of the generated households get faces from the pool, one photo ethnicity per family, with no face repeated on a campus (decision 30).

  • Small groups: the pattern in Small groups (decisions 33 to 40). The Cast has 8 active groups, 2 inactive, and 2 archived, planned into cast/groups; generated households get groups per campus at load time. Groups load with members, meeting places, attributes, history, Group Finder test cases, and weekly attendance on the church year.

  • Scanned check images for every check gift: five fictional banks (each with its own logo and paper color), a wallet per giver so card, bank, and check details agree, mailed business checks, bundled open fonts, and check scanner matching fields. Stored as Rock transaction images (decisions 25 to 27).

  • Combined and separate giving: most couples give as one giving unit, about 10% give separately, and adult children at home give on their own (decision 42).

  • Giving realism: check writers follow age and gift size, onsite givers catch up after a missed Sunday, amounts vary the way real gifts do, schedules change now and then, givers come and go, and the largest givers give stock now and then. Giving passes 191 of 196 measured values (decision 43).

  • Giving analytics: Rock's giving attributes, bins and percentiles, journey stages with history, and three alert types with 12 months of alerts (decisions 44 and 45). Cast giving expectations are checked on every load (decision 46), and a version guard checks Rock on GitHub for changes to the code the loader ports (decision 47).

  • The builder and loader split: the builder writes one package per dataset (format 1: data only, a checksum for every file, byte-identical when rebuilt), and the loader library and CLI install packages. Each package is for one Rock major release, read from Rock's Rock.Version.dll, and names the oldest loader that can load it (decisions 52 and 158). Loads through packages matched the old direct loads exactly for all three datasets.

  • Kids check-in streaks and achievements: one Kids Check-in streak type, seven achievement types from High Five to Century Club, and each child's streak and attempts the way Rock computes them. Next-gen check-in shows them (decisions 57 to 61). Cast achievement expectations are checked on every load, the version guard covers the ported code, and a parity test runs Rock's own code on loaded data. Core 1 and Full 7 match Rock exactly.

  • Group photos: each of the Cast's 12 small groups has a photo of its leader and spouse, made from their profile photos from the group photo brief (decision 196). The original full-group photos are download-only assets. Every dataset sets them as the groups' photos, and Group Finder shows them on its cards (decisions 56 and 62).

  • The verify tool (decision 66): a trusted base made from the Rock release by its migrations, start-up steps, and first night of jobs (decision 170), a contract recorded from real loads, invariants, Rock's own Rock Cleanup job as a referee, the content standards as checks, and a receipt per package with a publishing gate.

  • Businesses at every campus: at least 6 on the main campus (all from the Cast) and at least 2 at each other campus, or the measured share of giving units when that is more. Every business has one or two contacts, loaded both ways as Rock known relationships, a work address, and gifts in the last 12 months. Every load checks all of it. Full 7 has 86 businesses, and both measured business values pass (decisions 63 to 65).

  • Every package passes the verify tool. The loader now sets what Rock's save hooks and Rock Cleanup would: primary aliases, age classification, family salutations, inactive families, an alternate Id and name metaphones for every person, and a Known Relationship group for every person (see How people load). The trusted base also runs Rock's first-night post-install job, without which Rock Cleanup blanks every age.

  • Prayer requests with an active prayer team (decision 67). Every dataset gets about 10 requests a week per 1,000 active adults, mostly from adults who attended, gave, or were in a small group, in Rock's own prayer categories, with text from content/prayer. The Cast's Prayer Administrator approves them, and the prayer team (the Cast's Prayer Team plus about 3% of active adults) prays through each one while it is active, as "Prayed" interactions with matching prayer counts. A few are flagged back to the approval queue, and some get comments, replies, and answers. The Cast has its own requests too, covering every prayer screen state, with 10 always from the last few days so even the small datasets show a full prayer list; every load checks them. Calibration part 5 grades it: all 87 prayer values pass on Full 7 with the crowd (about 11,100 requests and 67,000 prayers), and validation overall is 347 of 380 (91%).

  • Serving teams and serving opportunities at every campus (decisions 68 to 77; see Serving). Rock's Involvement connection type has eight polished opportunities with photos of real Cast volunteers, each placing people on its team at their campus. Every campus has eight teams with rooms, service times, staffing that fits the campus, and a background check for kids and student volunteers. Volunteers have rotations, preferences, and scheduling history over the whole history window plus six weeks ahead, and check in to serve. Connection requests in the measured mix lead to the teams, with activity history and person history. Validation grades serving and connections. Due dates run from each request's last status change, so most open requests are not due yet, some are due this week, and a few are past due (decision 173).

  • Notes on people (decision 78): six note types with View security (Rock's Personal, Pastoral, and Phone, plus Follow-up, Counseling, and Safety Alert), 89 hand-written Cast notes with 17 replies in 37 households, and generated notes from text pools. The Cast notes include the 11 from Rock's legacy sample data, which never loaded before, and notes on the staff families and Nancy Turner, whose profiles demos open first. Every load checks that each Cast note shows on its person's profile (decision 171). Calibration part 6 measures note use. The measured shape sets timing and length, and the volume and feature use are designed higher, because the sample church shows what good note use looks like. Full 7 has about 54,000 notes and 7,000 replies, and all 15 graded note values pass.

  • Security roles (decision 79): Cast people join the out-of-the-box roles their stories give them, mapped in configuration/security-roles.json, and each named campus pastor is in RSR - Staff Workers and RSR - Pastoral Workers. The load creates no roles.

  • The public site (decisions 80 to 82; see site/): why the sample data matters, Rock Solid Church and its building tour, a page for every Cast household, a Features page with a section for each part of Rock the data fills, the datasets, how it's built, and how to contribute. It is built from the repository's own files with no packages, and the brand page offers the logo as SVG and PNG, the palette, and every photo set as a zip. The logo now has vector versions, redrawn from the approved artwork. On 2026-10-28 it moved to sampledata.rockrms.com, and it now shows who to sign in as, the calendar's stages, each Cast person's username and note count, and load times read from datasets/*.json.

  • The adult Discipleship Path (decisions 83 to 87 and 89, 106 to 108; see Steps). Rock's program is built out to seven steps from configuration/steps.json, and every step comes from a record the data already has: group and team memberships, the giving journey, baptism dates, and real class dates. Classes are in progress at every campus, and Rock's program completions are written the way its job does. The Cast's stories (Ted Decker's completion, the Gilberts and Bri Hall in Starting Point) are checked on every load, and new invariants tie each step to its source. Core 1 has 438 steps, 64 baptisms, and 4 program completions.

  • Pledges (decisions 97 to 105 and 109, and the ones added as it was built; see Pledges): Built on the Rock, a two-year building campaign about 38% through on install day, on Rock's Building Fund, renamed Built on the Rock, with campus accounts, both pledge pages, and statement pledge settings. The Cast has 15 pledges and 3 givers with campaign gifts and no pledge, each story checked every load. Generated givers and businesses pledge at the profile's 12% of giving units, in every follow-through state, and validation grades the rate. The pledges and campaign gifts load with the loader's Giving part (decision 126).

  • The Student Path (decisions 87, 88, and 115 to 119; see Steps). A second step program, filed beside the Discipleship Path, with Student Camp, Follow Jesus, Mission Trip, and Student Leader. Its steps follow the student check-ins the data already has, on church-wide camp and trip dates, for designed shares of the students who could take each step. Students who decide to follow Jesus are often baptized a few months later on the Discipleship Path's Baptism step, and Rock's program completions are written for both programs. The Cast's stories (Ava Brooks at camp, Benjamin Lee's camps and trip, and Jasmine Washington's completed path) are checked on every load, and new invariants tie each student step to the student service. Jasmine's file now sets her graduation, so she checks in through her senior year. Core 1 has 13 steps on the Student Path, 3 student baptisms, and 1 Student Path completion.

  • The loader library is ready for Rock (decisions 120 to 126; see Using the library). It builds for .NET Framework 4.7.2 too, on Rock's own package versions, and packs as the SparkDevNetwork.Rock.SampleData.Loader NuGet package (each release publishes it to nuget.org; see Releases so far). A load can choose its parts, steps among them, reports progress instead of writing to the console, takes the server's PasswordKey and DataEncryptionKey, and refuses a database with people beyond a new Rock install under an application lock. SampleDataPackageIndex reads the hosted index.json, and SampleDataDatasets gives Rock's installer a card for each dataset, with people, households, install times, and database space (decision 216) measured from real loads that verify keeps current. Each index entry now carries that whole card too, so every release updates Rock's cards without a new loader in Rock (decision 144). loader-compat-check/ proves the key derivations give the same bytes on both builds, and that both builds read an index with or without the card fields.

  • Full 7 has its Crowd (decision 136). Its manifest lists 16,800 generated households across all seven campuses, so a load has 25,248 people in 16,967 households, where it had only the Cast's 185 people before. It loads in about 55 seconds with check images, and the package stays 14.6 MB, because the Crowd is generated at install time.

  • The Full 7 speed pass (see Performance). Every load step, part, bulk copy, and index rebuild is timed, and each verify receipt records the timings and the peak space. Loader 0.1.0-alpha.15 rebuilds each large table's indexes once instead of after every part that copies into it, so Full 7 loads in about 173 seconds instead of about 238 to 263, and its peak space falls from about 20 GB to about 13 GB. Loading the communication tables with their indexes on was tried, and was slower.

  • Attendance per person for students (decisions 146 to 148). An engaged student comes to the student service on some Sundays their family stays home (High School more than Jr High), and some keep coming for a while after their family stops. Generated adults aged 18 to 20 check in as students until they graduate, then attend as adults, and some come home from college only at Christmas, Easter, and summer. Every adult's and young kid's attendance, and every gift, is exactly what it was before. A load of main and of the branch with the same seed and anchor match row for row. Full 7 has 1,881 students, about 440 more than before, and three new invariants guard the rules.

  • Signing in as admin signs in as Alisha Marble (decisions 177 and 178). The loader turns Rock's own admin person into her, in the Marble family with Bill, with Rock's login, password, and roles kept. She connects the main campus's new requests to serve, at least 8 in every dataset, so her connection board, notes, texts, and groups all show real work.

  • Connection celebrations (decision 219). Connectors record the story behind a request as Rock's Celebration Note, so the Connections Hub and the Celebrations Report show them. Alisha Marble wrote six on the Cast's requests she is working, and generated requests get them by a designed share.

  • Communications (decisions 90 to 96; see Communications). Email, texts, and push with very large mass sends, opens and clicks, SMS conversations, one-to-one messages, and messages tied to steps. Slice 1 is done: the design, calibration part 7, and the church app stub. Source-1 has run part 7, and its communication shapes are in the profile. The plan now covers the Unsubscribe and Saturation reports (decisions 131 to 133), and part 7 measures saturation and a year of unsubscribes. Source-1 has rerun part 7, so the profile has its saturation shape, texted STOP rate, and unsubscribe timing. Slice 2, the setup, is done (decisions 137 to 141): the main and student texting lines and staff personal numbers (one per campus on Full 7), a weekly newsletter per campus and seven ministry and staff lists with members that follow involvement, the branded Rock Solid Church email template, and the message library in content/communications (49 emails, a newsletter built from pieces, and 32 texts and pushes). Isaac Silva is now the Student Pastor. Slice 3, bulk email, is done (decisions 149 to 151): two years of weekly campus newsletters, church-wide and ministry emails, Rock's send outcomes, opens and clicks with email clients, bounces, unsubscribes that follow Rock's rules with History, two scripted Cast unsubscribes, and validation grading part 7. Full 7 has about 1,500 sends and 1.3 million recipients, and the communications step took about 80 seconds then (about 176 with every slice; see Performance). Slice 4, texts and SMS conversations, is done (decisions 153 to 155): mass texts on the main and student lines, replies with staff answers, texted STOPs that turn off texting, the Cast's 16 hand-written threads, and generated conversations mostly on staff members' personal numbers, all graded against part 7. Slice 5, one-to-one messages, is done (decisions 159 to 160): serving confirmations and reminders, connector follow-ups, prayer celebrations, first-visit welcomes, and the Cast staff's 14 personal emails. Slice 6, push, is done (decision 161): the church's app site, devices for about a quarter of active adults, and two years of pushes with their opens. Slice 7, messages tied to steps, is done (decisions 162 to 163): class emails and texts to each Starting Point Class and Foundations course, baptism follow-ups, and the finished After Starting Point flow. The communications build is complete.

  • Event images (decisions 176, 184, and 197): all 51 calendar events have an approved 2:1 image, a titled design or a photo, set as each event's photo in every dataset and shown on the public site's church and brand pages.

  • The church calendar (decisions 174, 175, and 183; see Calendar). 51 events, each mapped to its Ministry by Design stage, on Rock's Public and Internal calendars in every dataset, at each dataset's campuses: holidays, classes, student, kids, men's, women's, outreach, and campus events, and six staff events. Dates follow the same rules as steps and messages, and Cast stories pin the car show, the men's breakfast, the diaper drive, the serve day, and the student retreat. Rock's four sample events become church events in place. Every event has its image, a titled design or a photo (decision 197).

  • Load timings (see Performance). The loader reports a timing with each step, the parts of its largest steps, each bulk copy and index rebuild, the commit, and the whole load. Verify saves them in each receipt, with the load's peak data and log space. Performance records where Full 7's time and space go, step by step, with candidate fixes.

  • Generated adult ages match the profile (decisions 166 and 167). Adults without children take what is left of each adult band after the parents, so many more are 18 to 24, and single adults make up the share of women that couples cannot. Every adult age band and every share of women by age now passes in Full 7.

  • Logins (decisions 179 to 182; see How logins load). When the person installing gives a password, the Cast's logins load from their files: the ten legacy ones (Alisha Marble keeps only Rock's own admin), every Cast person with a security role, 39 more whose stories suggest an account, and any Cast adult with the church app. Every campus pastor has one, and generated adults get one with the chance of their strongest reason in configuration/logins.json. Usernames follow Rock's own rule, such as tdecker. Every login uses the one password, hashed by Rock's own Database login (BCrypt), and no password or hash is in a package. Each login has Rock's person history, and every load sets each person's account protection profile the way Rock does. Core 1 has 63 logins, Core 3 132, and Full 7 5,293, about 31% of its adults (with decision 188). Verify signs in through Rock's own Database login on every dataset. It shipped in v0.1.0-alpha.14 on 2026-10-28 with the first signed index. Rock's installer block still needs its password field (see In progress).

  • Group sync (decisions 186 to 188; see Group sync). Five data views, filed under the church's own Rock Solid Church category, keep the Volunteers and Small Group Leaders lists, the RSR - Prayer Access security role, and two new care lists, New Here and We Miss You, in step through Rock's Group Sync job. The staff lists and the role send Rock's welcome and exit emails, and two make logins, but only for people who join or leave later: the loader fills each group as the job would leave it, and verify runs Rock's own group sync on every load and expects no change. The prayer team now always has logins, so Core 3 has 132 logins and Full 7 5,293. Core 1 has 47 volunteers, 8 leaders, 5 with prayer access, 4 on New Here, and 2 on We Miss You; Core 3 has 79, 16, 7, 6, and 2; Full 7 has 1,494, 318, 163, 346, and 152. It needs loader 0.1.0-alpha.15.

  • Staff (decisions 198 to 203): 23 named staff, every one a Cast person in configuration/staff.json, with a fixed, named campus pastor at every campus. A campus pastor outside Phoenix lives on their own campus and loads only in datasets that have it. Notes, calendar contacts, first-visit welcomes, and campus texting numbers use the named pastors. Every Cast profile photo and all 23 staff photos are delivered: the 36 new people's on 2026-10-28, and the three new pastors' families and the staff photos on 2026-10-29. The site's church page shows the staff and each campus's pastor. Staff have a Staff person attribute category with eight attributes, including a staff photo, bio, and favorite quote for a staff page (decision 201). They fill Rock's org chart: seven Organization Unit groups, each with its leader and staff (decision 202). Every pastor on staff is a man, and the women on staff hold director and leader roles (decision 203).

  • Event registrations (decisions 189 to 195 and 205 to 215; see Event registrations). Ten registrations tied to calendar events, linked so each event page shows Register, with some open on every install day so each feature can be tried. Students, kids, and adults registered, with fees, discounts, payments, payment plans, wait lists, and placements, and last summer's campers match their Student Camp steps. Students move up a grade the day after June 1, as Rock does (decision 205). Camp and the mission trip carry typed releases with Rock's verification hash and a PDF drawn at install. Each registration has Rock's notes and history, reminders look sent, and three data views sit under a Registrations category. All three packages pass verify on Rock 21.0.2 and Rock 20.0.10, with loader 0.1.0-alpha.15. Later: a refund, batch history, and registration emails as communication history.

In progress

  • Communication flows (decisions 220 to 222; see the flows proposal and Communication flows). Eleven flows that follow Ministry by Design, a Baptism flow that stops when the person is baptized, and a scheduled email, in four slices. Slice 1 is built: the flows live in configuration/flows.json with a category for each Ministry by Design system, After Starting Point invites people to Foundations instead of to serve, the new After Foundations flow asks people to serve and ends at the Serve step, and runs still under way on install day stay open, so Rock keeps sending them, only to reserved contact points. Slice 2 is built: the Baptism Interest workflow, the first workflow type in the sample data, puts people in Baptism Next Steps, four messages that stop when the person is baptized, with people mid-flow on install day. Slice 3a is built: recurring flows on the reports work's guarded views, with First-Time Guest Welcome, We Miss You (paused), and Baptism Sunday Invitation, and a verify check that the loader's audience rules and Rock's views agree. Slice 3b-1 is built: Women's Retreat Early Bird, the first Registered goal, and Lead a Group, before each small group launch. Slice 3b-2 is built: Student Camp Registration, Christmas at Rock Solid with a push and no goal, and people who leave a flow from its unsubscribe link. Slice 4 is built: Built on the Rock Follow-Up, the One-Time flow, which ran once the Monday after Commitment Sunday and shows Completed, and the scheduled Christmas Eve email, the one communication that waits to send after install (decisions 247 and 248). Next: flow pushes beyond Christmas, and people made inactive.
  • Data views and reports (decisions 223 to 234; see Data views and reports). Slices 1 to 8 are built: the church's data view and report categories, locked to staff, with Leadership locked to pastors, Safety and Finance locked to their roles, and a Staff Workspace staff can build in, Rock's Foundational Views renamed Foundational Views (Shipped), and the layered data views in configuration/reporting.json. They are foundations, the Ministry by Design stage views built from steps, next-step views filed by Ministry System, the communication flows' audiences with their email guard, the Safety and Finance views, and 25 reports, from the pastors' path reports to Top Givers, locked to Finance Administration. Verify runs every view through Rock, checks every report's columns and Lava in Rock, and asks Rock's own security check the walkthrough. All three packages pass verify on Rock 21.0.2 and Rock 20.0.10. New Here and We Miss You are rebuilt on the foundations, so they now need an email address: Core 1 has 3 on New Here and 2 on We Miss You, Core 3 has 4 and 2, and Full 7 has 270 and 117, every view and report has a run history with one retired view, and each Ministry by Design stage has a weekly Rock Metric with values back to when its view was made. Packages need loader 0.1.0-alpha.17, since an older loader cannot read the category security or rename Rock's category. Next, if Jon wants it: a reporting page on the site.
  • The Sample Data Installer block in Rock, built in the Rock repository against the loader package. It shows Core 1, Core 3, and Full 7 as cards built from the package index, so each release updates them, and downloads the chosen package from a hosted index.json, beside the old sample data block. It landed on Rock's develop branch on 2026-10-27, on loader 0.1.0-alpha.13. What is left: one Rock change that bumps it to the newest loader, which gives Rock the signed index check, and adds the login password field, and a page for it in Rock.
  • The release workflow (decisions 127 to 130; see Publishing a release). .github/workflows/release.yml builds each Rock release in release/rock-releases.json, writes and verifies every package, and runs the publishing gate. On a version tag it pushes the loader to nuget.org and uploads the packages, receipts, and index to Azure, the index last. A dry run on GitHub's windows-2025 runner on 2026-10-22 built Rock 21.0.2, ran SQL Server 2025, passed verify on all three packages, and passed the gate. Its Packages job took 66 minutes (about 30 to build Rock, 6 for SQL Server, and 28 for verify). A self-hosted runner stays a fallback. The one-time setup in Maintaining is done (2026-10-22): the Azure identity and its role, nuget.org trusted publishing for SparkDevNetwork.Rock.SampleData.Loader, and the release environment with its approvers and variables. What is left:
    • A stable release (for example v1.0.0), which updates index.json for every Rock. The first prerelease, v0.1.0-alpha.10 on 2026-10-23, published the loader to nuget.org and all three packages with index-prerelease.json.
    • Change the Rock 21.0.2 entry from a develop commit to its tag once Rock tags it, and the Rock 20.0.10 entry (release-20.0, added for v0.1.0-alpha.13) to the newest Rock 20 tag.
    • Rock 20 and Rock 21 packages from v0.1.0-alpha.13 on. Each package serves every dot release of its major (decision 52). On 2026-10-23, Core 1, Core 3, and Full 7 passed every verify check on Rock 20.0.10 unchanged, and its trusted base had the same schema hash as Rock 21.0.2's.
    • The first signed index (decision 172). The index signature is built: the Publish job signs the index with sampledata-index-1 in Azure Key Vault before it publishes anything, and loaders from 0.1.0-alpha.14 read only a signed index (see The signature and Signing keys). The vault, both keys, the signer role, and the variables were set up on 2026-10-27. v0.1.0-alpha.14 published the first signed index on 2026-10-28 (see Releases so far). What is left: bump Rock's installer block to that loader and add its login password field, in one Rock change. Raised by the Sentinel security review of the installer block (SparkStealth/Rock-Mirror#65). It is required before Cast logins, and before v1.0.0 fixes the index format. alpha.14's packages also raise the minimum loader to 0.1.0-alpha.14 (decision 158), because an older loader lacks the Calendar part, Alisha's replacesAdmin field, and the connection due-date fields.

Waiting on a decision

Nothing right now. (Tempe was confirmed as the seventh campus on 2026-10-16; see decision 19.)

Next

  1. Close validation gaps. First-time visitors run low. A few small samples, such as connection request months and holiday first times, sit near their tolerance and move with any change to who is generated (see Validation).
  2. Run the giving parity test against a running Rock: load Full 7, run Rock's Giving Automation job, and compare (see Validation).
  3. Real Crowd names from public-domain frequency data by birth decade.

To do (parked)

Ideas we agreed on but set aside for later. Move an item into "Next" when we pick it up.

Small groups

  1. Women's groups. Add women's small groups led by women, with a Women's Bible Study topic. Alisha Marble's existing group becomes one of them; until then it is not part of the small group design.
  2. Leader requirements. Use Rock's group requirements (for example, a background check for leaders), with a few leaders whose check is missing or expired so Rock shows the warning.

People

  1. Cast group membership that disagrees with stories. The Ortizes are active members of the Greggs group, though their story says they stopped coming six months ago, and the Ellises are in groups older than their first visit.
  2. The Cast's other known relationships. Some Cast people list can-check-in and allow-check-in-by relationships. Only business loads so far.

Serving

  1. A midweek student night. Calibration shows about 31% of check-ins on Wednesday, and the sample church has no midweek service. Set aside on 2026-10-19 while serving is built. Student Night is now on the calendar every Wednesday, because Cast stories describe it, but students still check in only on Sunday.

Steps

Both step programs are built (see Steps). These ideas from its "Later" section wait for other work or a reason to pick them up. Keep the two lists in step.

  1. eRA steps in Rock's Core Steps program, from the attendance the data already has.
  2. Links to learning and events. Foundations links to a learning class, once learning (LMS) is built. Last summer's campers are now registered for that camp, so a Student Camp step could point at its registration too.
  3. Student small groups, which would add a group step to the Student Path.
  4. Step workflows, such as a follow-up after a baptism.

Packages and loaders

The builder and loader are split (see Done). What is left:

  1. Configuration through Rock's services. The library now runs inside Rock (see Done and In progress), but it still writes configuration with SQL. Saving it through Rock's services would run Rock's save hooks.
  2. Download a package by version in the loader CLI (--version 1.2.0 --dataset core-1), once packages are hosted (see Publishing).

Publishing the loader to NuGet is in the release workflow (see In progress).

Publishing

Publishing packages to Azure is in the release workflow (see In progress). Signing the package index is built (see In progress).

Later (Phase 1 and beyond)

Connection requests beyond serving, learning (LMS), benevolence, reminders, and person attributes for the Crowd.

Open questions

These come from the design spec.

  1. Where dataset packages are hosted (the legacy data lived on storage.rockrms.com).
  2. Whether the Rock loader replaces the inside of the legacy SampleDataManager or sits beside it.
  3. Whether photos are stored in the database or through a file storage provider.
  4. The final meaning of each connection status in the journey.