MinistrElife Update: version 2.11
Many of you may recall the MinistrElife keynote Erica, Meg, and I presented during the Biennial. If not, here’s a link to the Facebook broadcast. During the Livestream, we shared a bit of where we’ve come from and where we are seeking to go with the launch of the new MinistrElife.
As shared during the presentation, our timeline is not fixed in stone. We are developing using an Agile software development process, which keeps the work relevant to the users of MinistrElife as we build out applications for mobile (Apple and Android), for web browsers, and for the desktop (Mac and Windows).
MinistrElife Development Roadmap (as of August 21, 2023)
Highlights
Here’s an overview of the primary features we’ve been working on since the Biennial:
Creating Posts and Adding Interactions: A core feature of any network is being able to add posts. In MinistrElife 2.x (ME2x) “jots” and “stories” can be created. Jots are short-form texts no longer than 250 characters. Stories are long-form, article-style writings. ME2x also allows its own “interactions” or ways of engaging with posts: Like, Love, Joy, Praise, Care / Hold, and Pray.
Interactions: Like, Love, Joy, Praise, Care / Hold, and Pray
MinistrElife and ABPS Profiles: In the current MinistrElife version we have a Basic Profile and the American Baptist Profile System (ABPS) profile. For ME2x we’re calling the Basic profile, the MinistrElife profile. We’ve got the initial versions of both of these running with the ability to download PDFs and print from the browser.
Mobile app versions deployed to the Apple and Google Play Stores: While the apps are deployed, they are not available for general use. They are behind a development wall and only available for select folks to use. As we enter into the closed beta, they will be released to select individuals for test before final release to the public.
Video Transcoder: ME2x allows you to share videos with others. The video transcoder utility allows for that video to be recorded via the browser or your mobile app, then converts that video into formats that other browsers and mobile apps can use (taking into account everyone’s different internet speeds), so that your friends and connections can view that video. We’ve finished the first version of this utility that generates both a high-def version and lower lower-resolution version for viewing our short-form videos, which we call clips.
This transcoder took nearly 4 weeks of continuous development and really does represent a significant accomplishment from the development team.Comprehensive Automated Build and Testing Process: There’s a lot that goes on in the background of a solid application development process. One of the key places of failure is not having a process that removes human error when sending code from the developer’s computer to the live production environment. We’ve built a process, or pipeline, that ensures every time a piece of code is developed, it is checked individually, then against all other new code, then against the whole application to ensure an extremely minimal impact on the existing application. The system even simulates every use click, scroll, form completion, and keystroke before moving to a final human quality assurance process for validation.
Detailed:
How much work has been done?
It’s oftentimes difficult to explain or know how the development process happens. Here are a few graphs that convey the load and efficiency of our team: Fasil, Raul, Dawit, and me.
Cumulative Flow Diagram - How many tasks the dev team has been working on since we started building in March.
Features Delivered: represents the number of net new product changes a team makes each month. It's calculated by multiplying the number of changes merged by the percentage of lines of code that are net new lines.
Features per Engineer (FPE) is calculated by dividing the number of features delivered each month by the number of active engineers on a team. FPE is a signal of organizational efficiency and typically decreases as teams grow.
Changes Delivered represents the total number of merged changes over a period grouped by the types of changes made during that period.
Feature: New work that extends existing code and adds new code
Churn: Work that modifies code that was previously added or modified within 21 days
Refactor: Work that modifies code that has been stable for at least 21 days
Changes per Engineer (CPE) represents the changes delivered in a time period divided by how many engineers actively contributed during that period. CPE is a signal of team efficiency. Teams with higher CPE are likely to have a streamlined review process and typically make more frequent, less risky changes.
Changes Delivered represents the total number of merged changes over a period grouped by the types of changes made during that period.
Takeaway:
Note that the changes delivered and the changes per engineer reflect the efficiency and churn (output) of the engineers in their work. This conveys the fact that our dev team is overly efficient in the development and review cycles of application development. And we’re just getting started.
