• quality of the solution
• satisfaction with the result
• cost

How can you add value for the customer by reducing risk or cost?

I propose 4 types of customers:

1. Regular customer: straight work for hire.
2. Reference customer: provides a private reference for my work to a potential customer.
3. Sponsor customer: the company is publically promoted as a user of the product.
4. Partner customer: actively promotes the product within their market.

Regular customer

The customer receives a proposal for their project. Engages in discussions regarding the scope of work, pricing, and other details. Once the contract concludes, there is no continued relationship with the client.

Reference Customer

A reference customer starts as a regular customer. As part of the contract, they agree to talk with potential clients to discuss:

• the project scope,
• the benefits of the solution,
• and the overall business impact of the work performed.

Contracts are protected by a non-disclosure agreement to safeguard the confidentiality of references. This allows prospective clients to better understand the value proposition. But it prohibits them from sharing any proposal-related information outside their organization.

In exchange for serving as a reference, these customers receive discounted rates on their contracts.

Sponsor Customer

A sponsor customer is a reference customer who has consented to publicly associate their company name with the solution/product. This association includes prominent visibility on websites, emails, and various marketing materials.

Sponsor customers receive a greater discount on their contracts compared to reference customers. They may enjoy other benefits, such as enhanced support agreements.

Partner Customer

A partner customer can be in any of the other customer categories. Unlike the other customers, who take a passive approach to supporting the product, these customers actively advocate for the product.

They share their positive experiences with others in the same industry. This strategy is particularly effective when the product offered is not a primary focus or distinguishing factor for the customer's business.

Rather than receiving discounts on contracts, these customers benefit from additional revenue when a client they refer decides to purchase the solution.

Conclusion

Offering customers an ongoing role in the success of your business can reduce their concerns about your solution. This win-win approach to negotiating contracts can also reach new clients and help answer the concerns of new clients.

What are your thoughts about these customer categories? What tools/techniques do you use to help customers get to yes?

(A good reference on negotiating is https://www.amazon.com/Getting-Yes-Negotiating-Agreement-Without/dp/0143118757.)

#opensource, #Business, #DevTo

The request was for the reference to look like:

  issue2345: title of issue

In Roundup, object designators like issue2345 are automatically hyperlinked to the corresponding object.

The code I recommended used a button to trigger this operation. It also used the clipboard API. When clicking on the button (or hitting space or return while focused on the button) the reference format above will be copied to the clipboard. Triggering the clipboard API must be done by a user interaction. For example: activating a button. If the browser does not support the clipboard API, a simple alert() is shown.

In addition to copying to the clipboard, the user gets feedback when the text of the button changes to “Reference copied”. Then it resets to the original message after 2 seconds. Since clicking the button multiple times is idempotent, there is no sense in disabling or debouncing the button. Note, this is unlikely to be a11y compliant as I don't think the change of button text is announced. If anybody has some ideas on how to make this more compliant, leave them in the comments. Maybe using aria-live="polite" or "assertive" on the button element would do the trick?

Here is the code I suggested:

<button id="copyreference" type="button"
            tal:condition="context/is_edit_ok">
   Copy Reference
</button>

<script tal:attributes="nonce request/client/client_nonce">
  (function () {
    "use strict";

    let crb = document.querySelector("#copyreference");
    if ( ! crb ) return
    crb.addEventListener("click", async (e) => {
        e.preventDefault()
        if ( ! navigator.clipboard ) {
            alert("Clipboard is not available")
            return
        }

        let issueDesignator = new URL(document.URL)
            .pathname
            .split("/")
            .pop()
        let issueTitleText = document.querySelector("#title").value;

        await navigator.clipboard.writeText(`${issueDesignator}: ${issueTitleText}`)

        let originalCrbInnerText = crb.innerText
        crb.innerText = "Reference copied"
        setTimeout(() => {
            crb.innerText = originalCrbInnerText}, 2000)
        }
    );
  })();

The flexibility of Roundup allows the administrator to rewrite all of the HTML used in the web interface. As a result, I based my guess of CSS selectors on the HTML generated by the classic issue.item.html TAL template.

The button could be placed anywhere on the page and the script (including the nonce required by the CSP) would be placed anywhere after the button. Probably at the end of the page so it doesn't block rendering.

The classic structure of the issue display page for users with editing capability included an input with the id title. This is retrieved using the id and included in the string written to the clipboard.

A user without editing capability for the issue (or without editing capability for the title attribute of an issue) does not have an input with id="title". In these cases, the admin would have to modify the issue.item.html template to add an id of title to the enclosing element. Then the code above would be modified to replace:

let issueTitleText = document.querySelector("#title").value;

with:

 let issueTitle = document.querySelector("input#title");
   if ( ! issueTitle ) {
     issueTitle = document.querySelector("#title");
     issueTitleText = issueTitle.innerText
   } else {
     issueTitleText = issueTitle.value
   }

In my original example, the button element is generated only if the user can edit the issue. Removing the tal:condition attribute would always display the button.

There is nothing with an id or CSS selector that contains the object designator. I use the final element of the path of the URL to get the designator.

I chose to use the IIFE code structure. This allows me to use the early return pattern if the button is not found. If anybody knows how to do the equivalent of an early return without an IIFE or other function in a script tag, leave your trick in the comments.

If you use the Roundup Issue Tracker and have your own enhancements, feel free to mention them in the comments. #WebDev, #opensource #RoundupTracker #DevTo

Shakespeare once said “A rose by any other name would smell as sweet”. I wonder if something similar can be said for software releases.

I am planning a new release of the opensource Roundup Issue Tracker. Historically, release schedules were on an as needed basis. Before 2006 (when version 1.0.0 was released) there were multiple years with more than 10 releases (including alpha/beta and other pre releases).

But there were no releases from 2013 until 2016. Also, there was a gap in 2017. There was significant development done during those years without releases. But only those willing to run code from the repository were able to benefit. In 2018 I took over as release manager and chose to start doing yearly releases.

Why Release

With opensource projects, there are many reasons to release: * get features/bug fixes to users * thank contributors * increase project visibility * establish expectations * provide deadlines

As I mentioned above, producing a release makes the work of contributors (developers, documentation writers, people reporting issues) isn't generally available. Frequent releases align with my preference to reduce WIP (work in progress). Thanking the contributors by releasing their work helps drive enthusiasm and engagement.

Announcements on multiple platforms accompany each release. When I see another issue tracking/bug reporting program release announcement, I experience FOMO over the marketing provided by their announcement.

A regular release cadence helps users to schedule time for testing or upgrading the software. Also, regularly scheduled releases encourage developers to finish their work and get it into a release. This deadline also drives me to go through all the steps to generate a beta and final release. This year (2023) will be my 6th yearly release.

When to Release

Although I do believe that reducing WIP is important, Roundup is not provided as a SAS (software as a service). It is deployed on-prem and meant to be customized. Some changes to Roundup require changes to a customized installation as part of the upgrade. For example:

• upgrade from Python 2 to Python 3 can require rewriting a tracker's business logic
• support for newer databases versions can require table alteration (sometimes manual, sometimes programmatic using the roundup-admin migrate command)
• security improvements and CSRF protection require changes to customized HTML templates.

I mentioned my FOMO when seeing other products release multiple times a year. I often see releases with 5 or so changes. Often these changes fix cosmetic issues or broken fields in the web interface.

With Roundup, many users have redesigned/replaced part of the interface. A release only supplies changes to the reference interfaces. The Roundup administrator needs to merge the reference changes into their production interface. In Roundup, changes can be implemented in production without requiring a release. This separation of concerns between the Roundup core and a customizable tracker makes Roundup more flexible. But, increases the work required during an upgrade.

Because of how customizable Roundup is, I try to balance between WIP and the churn caused by frequent releases. Yearly seems to be a sweet spot. There are occasions when a new core feature needs a change/bug fix. In that case the user has a choice to wait for a new release or use the most recent commit to the development repository.

If Roundup was a SAS with more limited customizability, we could do canary deploys directly from the repository. This would positively affect:

• getting features/bug fixes to users
• thank contributors

but would also reduce the utility of Roundup. Setting up a Getting Things Done tracker for his/her family would find it very difficult in a SAS based model. Also, the tempo of releases in a SAS based model may not align with the user's needs for a stable platform.

If Shakespeare were a software writer would he have penned “Would software by another release schedule smell as sweet?”. Leave your thoughts in the comments.

(Cover Image by Glen Carrie)

#webdev, #discuss, #opensource, #development

One of the things I have to do when developing a new tracker for the Roundup Issue Tracker is test on mobile browsers. When I run into issues, I used to hook up a remote debugger. This usually requires finding a USB cable as wifi is less reliable.

I really wish that mobile browsers had a native console that I could use to see console.log output and javascript errors. While not native, MobileConsole by hnldesign provides quite a bit of power by including one script and one style tag in my HTML page. At 45k uncompressed (17k gzipped) it's sized between the smallest and largest mobile consoles I found. It can be seen at the bottom of the web page:

It supports the usual console output functions (error, ... debug). Plus it supports console.time/timeEnd and console.trace along with the group family. It also displays objects collapsed and allows you to toggle them open. The console can be resized allowing you to reduce the screen real-estate used on a mobile device.

It has some areas for improvement: * it only opens objects one level deep. So an array in an object is displayed but you can't expand the array further to get access to its elements. * grouping is not nested or collapsible. But this is noted as an area for improvement.

If you do a lot of logging, you might want to download the library, open your editor, and apply a change that reduces redraws triggered by console output.

One thing to note is that running commands in the console will not work if you are using a Content Security Policy (CSP). Any CSP that does not allow 'unsafe-eval' will prevent console commands from running. But at least you will see the error in the console 8-).

There are other mobile consoles as well:

• mobileConsole is the smallest at 5k, but appears to only support console.log. Documentation is sparse and there is no demo.
• B1naryStudio js-mobile-console – is 6k in size. It has methods to show/hide, enable auto-opening on error, and create command aliases. However, in its demo, I had issues with it displaying document.querySelect('body'). All it showed was an empty object {}.
• Eruda is a console with a size of 130k gzipped. However, with that size, you get an element browser, network monitor, and other tools you know from your desktop browser's DevTools. It also has a plugin ecosystem. It properly handles console.group as a toggle. Also you can submit multi-line scripts. I think the only thing Eruda is missing is a debugger 8-).

Using hnldesign's MobileBrowser I was able to figure out why my javascript was crashing. If your hardware can handle it though, Eruda has many more features to make debugging on mobile device easier. Now the only time I need to find a USB cable is when I have to debug using breakpoints.

#WebDev #DevDotTo #OpenSource, #javascript

A user requested a task timer. The workflow:

• open an issue page,
• start a timer,
• start the task associated with the issue,
• use the issue page to document the work.

When done, the user would:

• stop the timer,
• finish documentation, attach files, and make other changes to the issue,
• submit the time and other changes.

There are a few decisions to make:

• timer functions
  • is start/stop enough?
  • is pause/restart needed?
  • does the user need to change/set/edit the timer?
  • do we need to track seconds, minutes, and hours? Since the customer is billed for the time, recording seconds seems excessive. Is there a scenario where the timer would need to record seconds?
• timer controls
  • do we use a button/buttons? Does checking a checkbox activate the timer?
  • what does the UI look like for each timer function? Are the controls in the issue page? Are the controls in a floating popup? Does the popup need to be movable/collapsible so it doesn't block access to the underlying issue?
• notification feedback
  • how is the user notified that the timer is running/paused/stopped?
  • how does the user see the elapsed time?
• future planning
  • how to add controls without cluttering an already complex interface
  • what impact will this have on adding future feature requests in the same context
  • does this guide us in implementing future workflows

Evaluating a Command Palette

I decided to try to install a command palette. A command palette is a UI interface usually activated by a hotkey. It allows searching and selecting from a context-sensitive list of commands. You might be familiar with the VS Code command palette. Command palettes have many advantages for users:

• discover useful commands (and their shortcuts)
• faster than scrolling down a long list of commands
• keyboard is faster than using the mouse
• invisible until activated
• make commands available that wouldn't be important enough to get a button or other UI element

There are many command palette implementations in JavaScript. Some are used with specific frameworks. For example, kbar is a React component and spotlight is a Laravel component. I wanted one that would work with Vanilla JavaScript. I identified two candidates:

• command-pal – “The hackable command palette for the web, inspired by Visual Studio Code.”
• Ninja Keys – “Keyboard shortcut interface for your website that works with Vanilla JS, Vue, and React.”

Ninja Keys uses Lit while command-pal uses Svelte. I don't have any experience with either, so.... Both of them can bind any command on the palette to a hotkey thanks to hotkeys.js. Both are MIT licensed. Command-pal is larger in size, but it also bundles all the libraries it needs. It looks like Ninja Keys loads libraries/modules on demand from CDNs on the internet. Being able to use the library without internet access is a nice feature.

Command-pal promotes itself as “hackable”. This usually means flexibility and sometimes simplicity. I like both. Command-pal's feature set wasn't as impressive as Ninja Keys. But it does include a floating button to trigger the command palette on mobile. This is a nice touch as moving the page to access UI elements can be tedious on mobile.

Adding command-pal

As a result, I chose command-pal. Integrating it was easy. I downloaded the file from the CDN. I also downloaded the dark theme from GitHub. I added a script tag and stylesheet link to the top-level page Roundup template file. This makes command-pal available on all the tracker's pages.

To invoke it, I added:

 const c = new CommandPal({
   hotkey: "ctrl+space",
   hotkeysGlobal: true,
   commands: commands,
 });
 c.start();

inside a script tag. The tracker is a web application. Sadly, the classic command palette hotkeys: “ctrl+k” or “ctrl+shift+p” are already used by the browser. I also wanted to activate the palette using the hotkey when focused on an input, select, or textarea. hotkeysGlobal: true should do that, but it didn't work for me in Firefox, Chrome, or Brave). I submitted a pull request to fix it.

The commands array included:

  [
    {
      name: "Exit Command Palette",
      contexts: [ "all" ],
      weight: -10,
    },
    {
      name: "Initial Screen",
      description: "Screen shown after login.",
      contexts: [ "all" ],
      handler: () => (window.location.href = "."),
      shortcut: "ctrl+i",_
      weight: 5,
    }, ...
]

Besides the fields used by command-pal:

• name,
• description,
• handler,
• shortcut

I added extra fields:

• weight
• contexts

These were inspired by the Superhuman blog on building a remarkable command palette. Among the things they suggest are:

• order commands by popularity/utility
• listed commands are context sensitive

The commands are initially sorted by weight (using commands.sort()). This displays the most popular (highest weight) commands at the top of the menu. Displaying the search results sorted by weight is an ongoing project.

The command is shown if its contexts property matches the current context. For example, the task timing commands only make sense when editing an issue. They should not be shown when viewing a list of issues, or a user's profile page. Inspecting the page's URL determines the current context. The code filters the command list, eliminating commands that are not appropriate for the context. Only then is CommandPal invoked.

Enhancing command-pal and Handling a Showstopper

The Superhuman blog post lists other desirable features for a command palette:

• fuzzy search (for mispelings 8-)) – is included in command-pal using fuse.js. (It looks like there is a fork of Ninja Keys that has fuzzy search support.)
• icons – I created an issue and pull request to add support
• synonyms – the fuzzy search includes the description field. This helps broaden the matching terms. But a description shouldn't be a keyword/synonym list. fuse.js can search an array of strings that are part of an object. Adding this functionality is a work in progress.

One interesting possibility is supporting multiple command palettes on a page. Each palette would have a different set of commands. I am not sure that's a good idea. Superhuman suggests making the command palette omnipotent. Multiple palettes force the user to make a decision about which palette to activate. This breaks the idea of “don't make me think”. I was able to create and activate multiple palettes with different hotkeys. However, more work on supporting multiple palettes on a page is needed.

At its core, a command palette is a large select modal. Having the ability to activate the modal from Javascript could allow the palette to be used in more places without making the user think.

I am pleased with command-pal. I have found it quite hackable even though I have never used Svelte before. However, I did have one potential showstopper.

The tracker uses a Content Security Policy (CSP). Style blocks in the page include a nonce. If the nonce is missing or doesn't match the one in the CSP the style blocks are ignored. Svelte generates style blocks for each element that it creates/injects. These client-side blocks, don't have access to the server's CSP nonce. If they did have access to the nonce, the nonce would be useless for securing the page's assets. If the style blocks were in a file that could be fetched using a stylesheet link, everything would be fine. However, efforts to do this with Svelt have failed. Another alternative is to generate a secure hash (sha256, 384, or 512). How to get this generated at build time is unclear. However, I did find a way to calculate it at runtime that seems to work. I proposed a patch to allow an administrator to generate the hashes using the command-pal library.

The mechanism for controlling the task timer is done. Now to turn my attention to actually timing tasks.

Let's Time All The Things

I chose the easytimer.js library. It supports:

• setting an initial value to start counting time
• one minute timer granularity – to reduce CPU load
• pausing and restarting timers while keeping their accumulated time.

The command palette allows the gross controls: stop/start/pause/resume. I still need to handle the other parts of the UI. The existing issue page provides a field for manually entering the task time. Rather than trying to create a new UI for the timer, I reused the existing field. The UI is relatively simple. There is a “Time spent” input element referred to as the “time element” below.

1. If the user prefills the time element with a number of minutes, the timer will start counting up from that time. This is helpful if you forgot to start the timer and start it after say 10 minutes.
2. The use case only requires 1 minute precision. Since I am counting in minutes, I add one minute to the start time. This rounds the time up to the next minute.
3. The time element is updated only once a minute. This is great for reducing CPU use, but poor for user feedback. There needs to be some way to notify the user that the timer is running. This needs to work without interfering with the ability to use the rest of the issue interface. Using a popup could work. But popups clutter the interface. If it can't be moved, it may hide something the user wants to use. Instead, I cycle the background color for the time element from yellow to goldenrod every 5 seconds. This is done using CSS rather than javascript. It should perform better than updating the input with a flashing indicator every second.
4. The animation stops when the timer is paused. But the yellow background color is still shown in the time element.
5. When the timer stops, the background of the time element returns to white.
6. Besides the time element displaying state, other elements of the page change as well. Starting the timer makes a pending change to the issue. The issue page already has a mechanism for indicating a page with a pending change. Starting the timer triggers this mechanism. This results in:
   • a change in the background color of the time element label (“Time spent”)
   • a change in the background color for the H1 header on the page
   • the H1 header on the page gets “pending changes” appended
   • the title for the page has an exclamation mark prepended to it; allowing the page to be identified in a list of page titles
   • the favicon for the page is overlayed with an exclamation mark inside a yellow dot; allowing the tab to be identified if the text can't be shown.

The command-pal Javascript Entries

Here are the three commands for working with the timer:

// more commands
{
  name: "Start or Unpause Timer",
  description: "timer",
  contexts: [ "issue.item" ],  // only show timers on an issue page
  handler: () => {
    if ( ! window.userTimer ) {
      try {
	// create the object
	window.userTimer = {
	  timer: new easytimer.Timer({precision: "minutes"}),
	  timeField: document.getElementById("time"),
	  animation: null,
	}
      } catch (err) {
	alert(`Error: ${err.name} - ${err.message}`)
      }
    }

    let timer = window.userTimer.timer;
    let timeField = null;
    if ( window.userTimer.timeField ) {
      timeField = window.userTimer.timeField;
    } else {
      alert("Unable to find 'Time Spent' field. Are you viewing an issue?");
      return;
    }

    if ( timer.isRunning() ) {
      alert("Timer is running for: " + 
	    timer.getTimeValues())
      return;
    }

    // restart timer
    if ( timer.isPaused() ) {
      timer.start();
      alert("Timer restarted at: " + 
	    timer.getTimeValues())
      window.userTimer.animation.play()
      return;
    }

    // start timer instance
    let timeValue = parseInt(timeField.value);
    if (! timeValue || isNaN(timeValue)) { timeValue=0; }
    // round up time to next minute: 10 seconds -> 1 minute
    let startValues = { minutes: timeValue + 1 }

    timer.start({
      startValues: startValues,
      callback: function (timer) {
	let timeField = window.userTimer.timeField
	timeField.value = timer.getTotalTimeValues().minutes;
      }
    });
    alert("Timer started at: " +
	  timer.getTimeValues())
    window.userTimer.animation = animate_timer(timeField);

    timeField.value = timer.getTotalTimeValues().minutes;

    // mark field/page with a pending change
    timeField.dispatchEvent(new Event('change',
				      {bubbles: true}))
  },
  icon: '<span class="icon">&nbsp;⏱️ </span>', // stopwatch emoji
  weight: 10, // sort this to the top of the list
},
{
  name: "Pause Timer",
  contexts: [ "issue.item" ],
  description: "Update time field and snooze the timer",
  handler: () => {
    if (! (window.userTimer && window.userTimer.timer) ) {
      alert("No timer was started.");
      return;
    }

    let timer = window.userTimer.timer
    let timeField = window.userTimer.timeField
    let animation = window.userTimer.animation

    if ( ! timer.isRunning() ) {
      alert("Timer is not running, time is: " +
	    timer.getTimeValues());
      return;
    }
    timer.pause();
    animation.pause()

    timeField.value = timer.getTotalTimeValues().minutes;
    alert("Timer paused at: " +  timer.getTimeValues());
  },
},
{
  name: "Stop Timer",
  contexts: [ "issue.item" ],
  handler: () => {
    if (! (window.userTimer && window.userTimer.timer) ) {
      alert("No timer was started.");
      return;
    }

    let timer = window.userTimer.timer

    if ( ! ( timer.isRunning() || timer.isPaused() )) {
      alert("Timer is not running, time is: " +
	    timer.getTimeValues());
      return;
    }

    let animation = window.userTimer.animation
    let timeField = window.userTimer.timeField

    timer.pause(); // stop time update
    timeField.value = timer.getTotalTimeValues().minutes;
    timer.stop(); // also zero's timer.
    animation.cancel();
    window.userTimer.animation = null;
  },
},
// more commands

(Note: the version of command-pal that I am running has the change to support icons.)

There is one helper function to set up the animation for the “Time spent” input field:

function animate_timer(input) {
  return input.animate(
    [
      {backgroundColor: 'yellow', easing: 'linear'},
      {backgroundColor: 'goldenrod', easing: 'linear'},
      {backgroundColor: 'yellow', easing: 'linear'}
    ],
    {duration: 5000, iterations: Infinity}
  );
}

Working Example

You can see this in action on the demo site. Use demo/demo for login. Activate the palette using ctrl+space. The code is also published.

#javascript #opensource #DevDotTo #WebDev

I have a B.S. in Physics which included some advanced computer science courses. But, my career ended up in system administration. I have taught and published a few peer-reviewed papers at conferences over the years. Trying to reduce toil and improve operations, lead to my interest in ticketing systems. Tools from LEAN and Six Sigma have proven valuable in analyzing ticketing and real-time logging data.

Issues Need Tracking

In 2002, I ran a lab that installed a system monitoring solution on Sun computers. We needed to track requests that came to the lab. I evaluated ticketing systems across a few dimensions. The Roundup Issue Tracker scored the highest.

Five minutes after downloading the software, I had a classic tracker running in demo mode. After entering a few tickets and adding a few keywords (tags), my co-worker and I decided it could work. It was flexible and looked like we could extend it to support our future growth. Little did I know that this was the start of a 20+ year relationship.

Roundup Basics

Roundup tracker has two components: the Roundup core and the tracker instance. The core is written in Python. The tracker instance supports one of two HTML templating engines: (Zope Page Templates or Jinja2). It is programmed in Python. The tracker instance controls the look/feel/functionality of the tracker. It:

• defines the database schema/data model,
• provides the web interface (with customizable HTML and CSS),
• executes Python code to validate entered data and react to a change (e.g. by emailing notification messages),
• can hook into the core code to control how the core operates.

One instance of the Roundup core can run many trackers. Each tracker can have a very different presentation and function.

Getting My Feet Wet

When I started, Roundup was still very new. I started developing my customized tracker to learn Python and experiment with Roundup. My tracker implemented several ideas from Request Tracker (RT). I developed the key components, replies/comments, dependencies, and grouping (parent/child), in less than 40 hours of effort over a few weeks. Roundup's implementation and documentation made building these significant features easy.

The other advantage was that Richard Jones, the developer, was in Australia. We set up a “follow the sun” development cycle. I emailed him a problem when I went to bed. By the time I got up the next morning, he would have a fix ready for me to use when I got home after work. This fast feedback is something I try to maintain in the Roundup community.

I never deployed my custom tracker, but the classic tracker worked well for the lab. As a result, the sales engineering group requested (and got) a tracker. After I left the company in 2005, they upgraded the Roundup core and converted the database to MySQL (from a dbm key/value store).

Back in a More Active Role

My next IT job used Request Tracker. I followed Roundup development but didn't contribute much. In 2012, there was some interest at work in setting up a customer-facing portal based on Roundup. I started development on my tracker again and re-joined the Roundup community. Over the next few years, I developed code to add:

• a transaction source property for data changes. Makes changes from the web interface but prevents the same change if it originated from (unsigned) email.
• the filter command to the roundup-admin command line interface makes data searching easier.
• nofollow relationships to links which makes Roundup less useful to spammers.
• CSRF protection using synchronizer tokens makes Roundup more secure.

Releasing Roundup

By 2018, Richard had stepped back, the last release was January 2016. I took over as a lead developer and release engineer. I released version 1.6.0 in July of 2018. This merged several existing patches, cleaning up Roundup's issue tracker.

Since 2018, there were two major changes added by other developers:

• support for both Python 2 and Python 3 (which required a 2.0.0 release)
• addition of a REST interface beside the XML-RPC interface

On July 13th, 2022, I made my fifth annual release.

Since Roundup deployments are on-prem, I established a yearly release cadence. Other issue trackers have more frequent releases. But, many of those releases address UI or workflow issues. In Roundup these are implemented in the (customized) tracker instance. So the user is not dependent on the fixes pushed from upstream. Each release includes upgrading instructions. These instructions can include changes for the tracker instance to bring it up to date.

The slower release cadence has an advantage for the users. It reduces the need to update tracker instances to once a year rather than every few months. However, the yearly cadence results in less public visibility for Roundup.

I plan more articles on developing and maintaining an open-source application. Some future topics I am considering include (in no particular order):

• The Customisability Trap
• Kitchen Sink Development
• Accessibility
• Responsive Design
• The Problem with Selects
• What?? No Javascript!
• Docker All the Things
• Colors and Themes
• The Bus Factor
• Evaluating Tracking Software

The Roundup 20^th anniversary article on lwn.net includes more information on Roundup.

I hope you enjoyed this article. Thanks for reading.

tags: #Python, #WebDev, #opensource #RoundupTracker #seriesRoundupTrackerNotesFromAnOpenSourceDeveloper #DevDotTo