All Activity

I opted to use this older thread, as it was about back-ups. I have my research/preparation notes that i added to a Curriculum file in JW Library (Elders School) One of my fellow elders is going to the school soon, and i wondered if there was a way to just share my notes attached to the jwpub curriculum (on my tablet) with the brother Thanks in advance

If he comes from a wealthy family, he probably is successful due to his connections and networking more so than his actual work product.

Maybe it helps if you change Group 1 to Group 01, Group 2 to Group 02 etc.?

Just like prepaid funerals, it is just dead money that goes into a pit.

In the Congregation>>Groups and Families like this:

A Look Behind the Scenes: How Baruch Handles Import & Integration Several brothers have asked whether Baruch is prepared to integrate with other systems like NWS, or whether it’s a closed ecosystem. I’d like to give you a small “behind the scenes” look at how Baruch is actually built. Import & Export Was Designed From Day One Baruch’s import system is not an afterthought. It is built as a modular pipeline with clearly defined responsibilities: Dedicated ImportContext Individual ImportHandlers A structured Importer pipeline Import types separated per domain (Congregation, Planner, Publisher, Territories, etc.) Diagnostics and progress reporting built in Each importer implements a specific ImportType and processes data through a chain-of-responsibility pattern. That means: Adding a new external system is simply a matter of writing a new importer module. The core system does not need to change. The architecture is open for extension, closed for modification. In other words: Baruch is prepared to connect. Proof That It Works: The “SampleData” Module Now here’s the interesting part. You can see that this architecture actually works in the SampleData component inside the Import module. Instead of hardcoding demo content, I deliberately use the same import pipeline to: Generate a complete fictional congregation Structure it as if it came from an external system Import it through the exact same import process So internally, Baruch treats SampleData as if it were importing from something like NWS. The only difference is that instead of reading a real export file, it reads generated test data. This means: The import engine is production-ready. It is not theoretical. It is used daily during development. It is capable of handling fully structured congregation data. Because this approach proves three things: Baruch is integration-ready Migration does not require reqwriting the core You can test Baruch with a fully configured congregation When you install Baruch, you can load a complete fictional congregation: Publishers, Assignments, Territories, Schedules, History, Reports. Everything is populated instantly. You don’t have to start from zero to evaluate the software. I didn’t want Baruch to become a closed island. From the beginning, I knew congregations may: Want to migrate gradually Want to experiment without risk Want to test with realistic data Want interoperability in the future So I built the import/export layer as infrastructure — not as a utility. If you ever wonder whether Baruch can connect — the answer is: The plumbing is already there.

Thank you for sharing your experience. It’s genuinely encouraging to hear that your congregation has found a system that works well — especially when even older publishers are comfortable using it. That is exactly what any tool should achieve. Regarding your questions: 1) Will non-territory data import from NWS? Yes — import functionality for non-territory planning data is part of the roadmap. The intention is to support migration in a way that: minimizes re-entry of information respects existing structures allows gradual testing The focus is primarily on structural planning data (assignments, roles, scheduling elements), not on centralizing personal records. 2) Will territorial assignments import? Territory management is currently placed toward the later stages of the roadmap. The reason is practical: in many congregations, territory handling is already managed through dedicated tools (for example Territory Helper), while the most immediate need I observed was in core congregation planning. My initial development focus has therefore been on essential scheduling and coordination within the congregation. Regarding import specifically: Baruch’s import capability depends on what NWS makes available through its export functions. I understand from their website that they support data import and export to other systems. The exact scope and structure of exported data naturally determines what can be imported reliably. Because Baruch is independent, integration depends on: what data is exportable how it is structured and whether that structure remains stable This part is not entirely under my control. That said, the import/export module in Baruch has been designed with integration in mind. It is modular and prepared to support structured data exchange with other systems where technically feasible. So while territory import is not the first priority, the architectural foundation is prepared for it. 3) Can it run parallel without interference? Yes. Baruch is designed to: Run independently Use its own local storage Avoid modifying or accessing NWS/NWP data There is no shared database. No shared cloud. No integration dependency. A congregation can run Baruch in parallel for weeks or months during evaluation. Nothing in NWS/NWP is altered or affected. Parallel evaluation is not only possible — it is encouraged.

I wish you have the tongue of an angel which means I hope it will come true.

I just read this now. Curious how he is a successful Architect at 18. This is probably more of a red flag to me than the age gap.

Jonathan ... excellent work even though its geek speak at least to me. Our congregation in Western Australia has been using NWS/NWP for everything (except Maintenance) for 3+ years now and the entire congregation love using it, even the oldies. In particular the Territory & Map functions for our entire territory which is 90% separate homes, and 10% flats, plus business territory. Thank you for implementing localized device storage like NWS & NWP as it removes the significant concern many appointed brothers have with cloud based programs, let alone issues of cellular unavailability. IFF we were at some point in the future, trialists of your system: 1) Will it import non-territory data from NWS? 2) Will it also import the territory mapping? 3) If all imported, can it run in parallel with NWS/NWP during the testing phase without interference from each other. Whatever the outcome, all the best in this endevour.

Always is a 1914 before a 2000 !!!!!! lol 😁

Thank you for the thoughtful questions — these are exactly the kind of discussions that help clarify design choices. Let me address them step by step. 1. Is there a complementary “publisher” part like NWP? Baruch is not designed as a direct clone of NWS/NWP. The focus is different. Baruch separates: planning coordination (appointed brothers) local personal data handling optional distribution mechanisms There is no central cloud profile containing personal data for each publisher. If publishers access information, they only receive the planning data relevant to them — never the full congregation dataset, and never personal records stored in the cloud. So in short: Baruch does not replicate the NWP model. It approaches the architecture differently. 2. If data itself is not synchronized, how are updates passed? This is the key architectural difference. Baruch synchronizes: planning objects anonymous identifiers structural changes It does not synchronize: names phone numbers addresses personal notes Each device maintains its own local mapping between anonymous IDs and personal data. When the secretary updates a record: the structural change is synchronized the anonymous ID is referenced local devices apply the change against their local mapping The cloud never stores the identity layer. 3. What about offline conflicts and queue handling? Baruch is designed as offine-first. Each device can: continue modifying locally queue changes resolve conflicts based on versioning and timestamps If a device goes offline: it continues functioning normally events are queued locally upon reconnect, a reconciliation process runs Conflict handling is deterministic and scoped to planning objects — not personal data. So the system does not “jam up” if a device goes offline mid-operation. Baruch does not use a publish/subscribe push mechanism. There is no real-time event pushing from the server to clients. Instead, Baruch uses a pull-based synchronization model. Here is how it works: Each device works fully locally. Changes are stored locally. At regular intervals, the device checks (pulls) whether new events are available on the server. If events exist, they are fetched and applied. If the device was offline, nothing breaks — it simply pulls pending events when it reconnects. There is no server-driven push. There is no dependency on continuous connectivity. What happens if a device goes offline after sending a change? Because synchronization is pull-based: The device commits its change locally. When connectivity is available, the change is transmitted. Other devices will only see the change when they perform their next pull cycle. This means: The app continues functioning normally while offline. There is no blocking state. There is no “jam” scenario caused by missing push acknowledgements. This is the reason why Baruch doesn't use Pub/Sub. Push systems require: persistent connections background listeners more complex session/state handling higher surface for synchronization bugs Pull is: predictable resilient easier to reason about less dependent on infrastructure complexity For congregation use, simplicity and reliability were prioritized over real-time immediacy. Near-real-time is sufficient for planning coordination.

My husband was 10 and a half years older and passed away 3 years ago. We never considered that he would predecease me. I had another suitor before I married dh, and did not consider his proposal bc he was a bit younger and I didn't want him to be teased. Yes, they did that then. Some traditions are baseless, but age differences should be considered for practical matters.

Saul’s account also highlights something quiet but powerful — the role of humble obedience after conviction. When Ananias arrived, Saul did not argue credentials, background, or prior zeal. He accepted direction from a disciple he would previously have viewed as beneath him. Later, Saul himself would write: “Clothe yourselves with humility toward one another.” (1 Pet. 5:5) His own life had already demonstrated that principle before he ever penned it. There is also the matter of immediacy. Acts says he “got up and was baptized.” There is no record of delay once understanding was clear. That pattern harmonizes with the counsel at Hebrews 10:22: “Let us approach with a true heart in the full assurance of faith.” Assurance leads to movement. And finally, notice that Saul’s baptism did not remove difficulty; it clarified direction. His trials intensified. In 2 Timothy 1:12 he later said: “I know the one whom I have believed.” That knowledge did not protect him from hardship, but it anchored him within it. Baptism is not an escape from pressure. It is a declaration of allegiance that redefines how pressure is endured.

Tuesday, February 17 [Saul] then got up and was baptized.—Acts 9:18. What helped Saul to get baptized? When the glorified Lord Jesus appeared to him, Saul was blinded. (Acts 9:3-9) For three days, he fasted and no doubt meditated on what he had just experienced. Yes, Saul became convinced that Jesus was the Messiah and that his followers practiced the true religion. There are lessons that we can learn from Saul. He could have allowed pride or fear of man to prevent him from getting baptized. But he did not allow that to happen. Saul was willing to become a Christian even though he knew that he would be persecuted. (Acts 9:15, 16; 20:22, 23) After his baptism, he continued relying on Jehovah to help him endure various trials. (2 Cor. 4:7-10) Your getting baptized as one of Jehovah’s Witnesses may lead to tests of faith or trials, but you will have help. You can be confident of the unfailing support of God and of Christ.—Phil. 4:13. w25.034 ¶8-9

Bro. Jonathan - glad you took the suggestion to establish a separate topic for your project. Looks like there is quite a bit of interest already.

Please clear something up: you say it's similar to NWS, which is used to schedule; is there a complimentary NWP part for every publisher? Also, you say the data itself is not synchronized, but what if, for example, the secretary adds/updates a record, how is that passed to the others? I believe the server queues tasks and redistributes them in order to the other devices. What if one device send a modification to the server but then goes offline and other events happen. Can the app continue to function locally (continue modifying, etc.) without being jammed up?

Thank you for asking. The core architecture is already implemented, and the application is actively under development. So it’s no longer just a planning phase — the foundation is in place. My intention is to release Baruch in phases rather than waiting until everything is “finished.” Each released set of functionality can then be evaluated and tested in a real-world setting. This allows for an iterative development process: Early features can be reviewed and validated Feedback can be incorporated immediately Adjustments can be made before the system grows too large Regional or practical differences can be addressed step by step By working in phases, we avoid building something in isolation that may not fully reflect real congregation needs. Instead, the application can grow in a controlled and thoughtful way, shaped by practical experience. Another advantage is stability. Each phase can be hardened and refined before moving to the next, reducing the risk of large structural changes later. I would genuinely appreciate your participation in testing when the first stable phase is available. Having thoughtful input from brothers with practical experience is extremely valuable, especially in ensuring that the workflows feel natural and realistic.

Hi, I had the same problem. Many siblings could no longer log into the app. I solved it this way: log into NWS from your PC, then click on the cell phone icon on the left and select "People in the App." Once you see the entire list of siblings who have installed the app, click on their name once and click "Refresh Person." Close the message that appears and click "Send App Data." Once you've done this, everything will work. Click "Apps" > "People in the App" Select the person Click "Refresh Person" Click "Apps" > "Send App Data" > "Prepare and Send" button.

Are you still in the planning phase? Or looking for beta testers?

Where exactly in NW Scheduler are you seeing your field service groups mixed up?

Baruch is designed as a congregation planning system (comparable to NWS) — specifically to support appointed brothers in organizing schedules such as Christian Life and Ministry Meetings, Public Talks, and other congregation responsibilities. However, it is not a traditional centralized cloud platform, and it does not use a congregation-sharing system for synchronization. Each device keeps its own data locally, and only anonymous planning events are synchronized between authorized devices. Each congregation works within its own environment. Personal data remains local on trusted devices, and only anonymous planning events are synchronized between authorized devices. So you can think of it as: - A congregation-focused planning system - with privacy-by-design architecture - rather than a central cloud-based platform. I hope that clarifies it — happy to explain further if helpful.

Is it a platform for congregations? I’m a bit unclear

I started the new topic on