Contribute

Help us build the church.

The most helpful thing you can tell us is a use case we're missing: something churches do in Rock every week that the sample data can't show yet. Tell us, and we'll build it into the church everyone shares.

What we're looking for

Big, common use cases first.

The sample data is meant to show each Rock feature the way most churches use it. Especially now, while the church is young, we're looking for the large patterns that touch many screens, not every small detail.

A great fit

  • A whole feature that looks empty. A Rock feature whose lists, charts, and reports would all be blank on a sample install.
  • A common kind of family. "Grandparents raising grandkids are common, and Rock should show how check-in and giving work for them."
  • A pattern most churches see. "Most churches see giving dip in summer and jump at year end."
  • Something a class or help article needs. "Our training on follow-up needs a few people who visited twice and never came back."

Better in your own test database

  • Rare combinations of settings that only a few churches use.
  • One-off situations you need for a single test or bug.
  • Small tweaks to one person's details, such as a different birthday or phone number.
  • Exact numbers from your own church. Every church is different, and the data aims for what's typical.

Not sure where your idea fits? Open an issue anyway and say how common you think it is. We'd rather hear it.

How to suggest a change

Open an issue.

For now, the way to contribute is to open an issue on GitHub. The team makes the changes, so we don't take pull requests yet.

Answer these four questions, so we can see who needs the data and how common it is.

Open an issue

  1. What Rock feature or screen needs the data? For example, "the Giving Overview's lapsed givers list."

  2. What should it show? For example, "three families whose giving stopped in the last six months, one with a scheduled gift still active."

  3. How will it be used? For example, a test, a help article, a demo, or training. Say if a test or article needs to name a specific person.

  4. How common is it? Say whether most churches would see this, or only some. Common patterns come first.

The ground rules

What every addition follows.

Everything is fictional

Every person, church, employer, and business is made up. No face may look like a real or famous person.

Reserved contact details

Phone numbers use the reserved 555-0100 to 555-0199 range, and emails use example.org, or rocksolidchurchdemo.com for church staff, so no real person is ever contacted.

Every household has a reason

Each Cast household has a story and a list of what it's used to test. If we can't say why it's there, it isn't.

Roadmap

What's next.

29 milestones are done, from the Cast and its photos to serving and prayer. Here's what comes next.

  1. 1

    Close validation gaps. First-time visitors run low and teens run low.

  2. 2

    Run the giving parity test against a running Rock: load Full 7, run Rock's Giving Automation job, and compare.

  3. 3

    Per-person attendance, so a teen can attend more often than their parents. The Student Path does not wait for it: its steps follow whatever student check-ins exist (decision 115). This work should also give recent graduates their student years: generated adults aged 18 to 20 were in high school inside the history window but never checked in as students, because only children carry a graduation year. Once they do, the Student Path shows their history with no change to the steps.

  4. 4

    Real Crowd names from public-domain frequency data by birth decade.