Interview with Saq Imtiaz

TiddlyWiki's Project Manager

I recently sat down with Saq Imtaz - the Release Manager for then next upcoming release and for almost an hour I was really impressed by this amazing volunteer to the community.

You’re the first project manager for a TiddlyWiki release - which is new for our community. What does the role mean in that context ?

I mean I’d say its not new in other open source communities, it is for us. TiddlyWiki has always been primarily Jeremy’s doing work at his own pace and his own schedule but welcoming contributions from others. And it’s been sort of discussed for a long time that you know in order to make them more efficient and remove bottlenecks, we should try to move to a different structure and way of doing things, where it takes some of the load off of Jeremy actually, so he spending less of his time with sort of maintenance and actually able to focus on other things. Not sure if quite gotten there yet, but this was meant as a step in that direction, so I think he was earlier this year that we moved the GitHub repository from being under Jeremy name to being under the TiddlyWiki organisation. So instead of jeremy/TiddlyWiki5 it became TiddlyWiki/TiddlyWiki5, and one of the reasons, well primary driver for doing that was exactly that, that having it owned by an organisation allows us to assign responsibilities to different people for different roles.

Its also the first time using GitHub’s Project dashboard - which shows us that Release 5.4 has 89 changes, 41 of which are done - Does that reflect the status of the release ?

I would look at that project plan a little bit differently in the sense that it is not necessarily intended that we get through everything on that list. Anything that potentially could be worked on has been added to that list, after which it becomes a case of who’s willing to work on something, we are basically entirely volunteer driven. So Jeremy sort of has his plateful already with a few large PRs that he started close to a year ago now that basically hasn’t the bandwidth to take on anything else. So how much of the other things we get done in time for 5.4 really depends on who else is willing to work on things.

Well, what we have done within that project plan as if you click over to the tab at the top called “Prioritized backlog”, those are the things that we sort of feel like our key features for 5.4. That absolutely need to get done, and the first four of those are all Jeremy. And since he’s more than halfway through all of them, they’re also not in the state right now where it’s easy for someone else to step in and contribute. So those are sort of the things that we think of a sort of being the cornerstones with the 5.4 release and everything else is a bonus and we’d like to get as many of them done as possible. But at the end it depends on what people want to work on.

From that point of view, I would say that we’re making very good progress on 5.4. The amount of things we have merged, I think is pretty impressive. However the exception of maybe one PR that has been merged from linonetwo that has to do with laying the groundwork for supporting WYSIWIG editing, and only the groundwork mind you. The other four big ones from Jeremy that I think are the key features are still in progress.

And you know part of the challenge, I think we’re Jeremy there is just finding the time to work on them because reviewing other peoples PR’s, providing feedback, merging them, that takes a lot of time. So its often difficult to find the time to work on the things that are actually assigned to you. I’ve been struggling a bit with the same where I feel like this is maybe the release I’ve put the most of my personal time into, but maybe with the fewest amount of direct changes to the code, because I don’t have the time to work on it. All the time I can commit to TiddlyWiki up being spent on the project management part of it.

So, it’s a shift also in terms of how we do things and different type of gratification as well. It’s nice to be able to help out in those role, but you miss out on that sense of actually being able to directly work on the things that you personally care about. So, it’s always a compromise in that sense.

It’s kinda mirrors what I do in my day job as well, where I wish I could do more hands on coding but I end up doing more management work, because as I’m reminded there is no-one else that can do that but there are many programmers. So I find myself doing the same thing now the TiddlyWiki -verse, which is Ok for now, but I’m hoping when we get ourselves into a better routine, I can also find a better balance there.

Another thing I think is worth mentioning in relation to the 5.4 timeline, and how far we are through the process, is that we’ve sort of made an adjustment along the way. Where instead of trying to be very ambitious with what we get done for 5.4 and it maybe being a release That’s like 12 to 18 months so away from what we first started talking about it. We are now actually hoping that early next year. This will be released so like January February time frame. And that is one of the reasons as well, we identified some key features we want to be present in 5.4, to get those out into the community so they can take advantage of them, but also allows community contributors to build upon them, and that way we shift our focus on a 5.5 Release. So the idea being to have these sort of milestone releases that introduce new features more often instead of making people wait a very long time for those features.

So keeping the community interests with future directions is a key consideration in the project planning ?

And that reasoning was precisely is why one of the prioritised that was assigned to me last week was to simplify the upgrade process for simplified TiddlyWikis, because if the idea is that we want to push out major changes more frequently than we want people to be able to operate as easily as possible. So it’s you know, that’s often something that comes up. So I think there are other things that Jeremy and I would rather I work on that would be more, you know, enjoyable from a programmer’s perspective, but it feels like from a community point of view this is what makes sense right now. So that balance is sort of something we always think about.

And you know a lot of the innovation that happens in TiddlyWiki actually comes from community contributors whether they’re directly contributing to the core or building plugins. So getting some of these new features out there, even though they are fundamental features that people who just open a new version of TiddlyWiki might not notice, allows people in the community to build on them. So rather than wait 18 months until that process can start the features that are ready should be shipped out as soon as we possibly can and that is part of the thinking here.

You mentioned your day job, and in your bio it says “UX designer, developer, doctor, non-profit educational sector jack of all trades, photographer and other things I often forget” - What actually is your job ?

Oh goodness, I work as a consultant, I run a small consulting company that works with IT development for non-profits in under-served parts of the world.

So under-served parts the world have a large potential to benefit from the use of IT. But the challenges are very different in terms of infrastructure, in terms of budget, in terms of social concerns that you have to take into account. And that’s where open source software has been a blessing and that’s actually what was my original driver to essentially become a self-taught programmer many many years ago. Via TiddlyWiki actually in the classic days. So this is like maybe 2007 or something because it allows you that possibility of customising things for specific demographics and their needs that is not really possible with commercial software at least not with the kind of budgets that we work under.

My original background was that I was trained as a medical doctor, and never really practised for long before pivoting towards working in the non-profit sector mostly in education and mostly in sub-Saharan Africa. Setting up schools, boarding schools that would transition to community owned at some point in time, and that was where the idea that we could do things more efficiently by leveraging IT came about. There were no solutions available that you could just pick up and use. I was having a hard time getting people to buy into my vision of how this could be done. So that’s where I ended up essentially teaching myself how to program and prototyping tools based upon TiddlyWiki Classic, that went far enough to show people, OK this is actually viable.

So, that’s how the shift happened towards programming and a good five six years after I’d already been doing that while working, I went back to school on the side, and also got a Master’s in UX Design. And again my focus in UX Design was, to be fair, more user-centred design than UX Design because with UX Design we think more about computer interfaces versus end user-centred design we think about all products and services as well. And again my focus there actually tends to be more on marginalised communities, and their needs because it tend to be different.

To give you a very obvious example, so you know one of the first apps that I worked on after that was for guiding women through pregnancy, but tailored for population with the extremely low literacy. So that meant very visually heavy designs and it meant things like text to audio and this is now over 10 years ago when these things were not so common.

The last release 5.3.7 had 22 contributors - Do you know how many are working on this release ?

No, I mean, I would have to sit down and count. What I can tell you is that as of last two years or so, especially we’ve been very very fortunate with our Chinese community members really stepping up in terms of contributions. Linonetwo has been a present, you know, a constant throughout the last two years working on some pretty challenging things and having the patience to see them through, because when you work on really fundamental things it goes through heavy review, heavy revision. It takes time. So the PR of his, that was merged, that lays the groundwork for WYSIWIG editing was probably in progress for like a year and a half and a lot of people would get frustrated and give up, but you know we tend to be very conservative with TiddlyWiki because of our backwards compatibility commitment.

So having the persistence and patients to work with us and see that through has been phenomenal. Another community member who goes by the GitHub handle Leilei332 is another Chinese community member has been phenomenal for this release in terms of both the amount of work they’ve done, but also taking on work that I would call grudge work. It’s not fun things. You know updating deprecated code marking it out where it needs to be replaced. It’s work that needs to be done, but it’s never enjoyable. It doesn’t give you that thrill of satisfaction, you know, working on a new feature does. He’s also been working heavily on accessibility, which I really appreciate and I know Jeremy does as well. Again the kind of work that isn’t, you know, most programmers who contribute to open source projects and do it to scratch a personal itch. They want to be able to build something, and there’s a missing feature or, you know, there’s something that personally interests them. So finding someone that’s working willing to work on these things, that really need to be worked on but maybe aren’t as glamorous, is fantastic, and it’s been high quality work as well. Which isn’t to, you know, diminish the work of any other contributors, but in terms of people who have really stood out for me in this release cycle I wanted to point them out.

Clearly there are some great contributors then to this release - but you don’t mention much of a collaboration process ? Is that fair to say ?

For the most part I think that’s accurate. I mean, I think it’s pretty normal for open source communities to work that way. If we may be had an approach where we were creating issues far in advance of things we want to work on let’s say. We’re already doing that for 5.5. Maybe then we would end up with a more collaborative approach for people would see that and maybe work on it. But at the same time a challenge tends to be that, you know, most of those features that we would possibly create issues for tend to be very fundamental changes for TiddlyWiki and getting them right so that you aren’t stepping on other subsystems or creating a clash that is going to be difficult to resolve later requires a very deep knowledge of the entire code base, which there’s not a lot of people that necessarily have.

So sometimes there’s also this feeling that okay, perhaps, we need to sort of get that process started ourselves in terms of starting a PR or starting work on the code and then if somebody else wants to contribute or take over, that’s great because you’ve sort of marked out what needs to be done. Which doesn’t mean we aren’t open to new ideas within that, but it’s often helpful because otherwise sometimes you end up with really large contributions from people, you know, that has taken a lot of effort and might be really high quality work, but can’t be merged because fundamentally there’s some sort of clash with the way we work in TiddlyWiki and it’s going to cause problems either with other subsystems or down the line.

So to avoid that duplication of effort, we do usually encourage people that if they want to work on something larger, create an issue for us. Let’s discuss it. And you know, go ahead and work on it

In terms of collaboration, it’s outside the 5.4 scope, but I think the work that Arlen22 is doing on MWS is a great example of collaborating with Jeremy on that. And I think now it’s a bit more Arlen22’s taking the lead, but Jeremy still guiding, but Jeremy had done the original prototype that Harlan rewrote, so I think that’s a good example of a collaborative approach. It does happen, but it isn’t the rule. I would say, it is more so that people contribute.

What challenges have you faced with this release ?

I mean there are always challenges, but nothing that I would say is you know dramatically different from working in any other kind of project. You have to always make sure that you provide feedback to people in a timely manner and part of what I need to do is mark out the tickets and issues that require a feedback and then Jeremy and I have pretty regular calls, and we’ll go through them together to make sure that we actually do provide feedback to people. Because that allows them to take the next step, you know, if we need to refine something about their contribution or changed direction than they need to know sooner rather than later.

Sometimes. You know you can have community members that get a bit impatient, which again is a completely human thing. I’ve been on the other side of this even within TiddlyWiki itself and it happens. And I think that there are things that we could do to make that easier for people to understand. So for example, Jeremy and I speak about once a week. He sometimes does take the time to go through the project plan and merge PR as on his own. If they don’t whatever doesn’t get caught we try to talk about and that weekly review, but that does mean that there might be a week’s wait until you know your PR gets attention, or if one of us is a way on vacation or something, and that’s going to be a longer wait. Another thing is that we tend to try to keep the way we work in GitHub relatively simple, and that’s to facilitate contributors who aren’t necessarily very Git savvy. So for example after a new release, for a few weeks, we won’t merge any PR’s. And we do that intentionally in case we find a critical bug that forces us to push out a bug fix release then we don’t want any other new changes in there. And there are ways we could do that with a different branch and still make it work, but we try to keep that process simpler for others. So for that code freeze, I feel like, if we were to communicate and actually put a date on it at the same time the release happens it may help people understand as well. Okay. There’s a code freeze right now. I’m going to have to wait for my PR to get merged.

For 5.4. There was an additional delay, because you know we made a pretty fundamental policy change, which is in terms of the JavaScript dialect that we support. Which we updated to ES2017. So that means covering browsers from about the last 10 years or so. But that required that we actually put into place some additional tests and scripts in the repository so that we don’t accidentally commit code newer than that. Because, for a lot of us who have been working with TiddlyWiki for a very long time, it’s muscle memory. We remember what old ancient dialect of JavaScript we have to use in TiddlyWiki. But once you say you can use something newer then its hard to remember where the border is right. So that was an additional delay, because it’s something we hadn’t done before so we had to get that in place, so that also meant that the merging a PR is was delayed.

Another learning for us was that we hadn’t set up the project plan for 5.4 during this waiting period so PR is that maybe were ready for consideration or merging there was no way to track them, and therefore some PR’s were only picked up recently or people had to remind us that, hey, this this one’s actually ready. Even though we try to review everything that’s open. Which is why a project plan for 5.5 is already there now. So as soon as we release 5.4 in that situation, we can just start adding them to the 5.5 plan, and it makes it easier for us to track or anything that we say in 5.4. Hey we’re not working on this now. We’re going to do in 5.5. We can automatically assign it to 5.5 and keep track of it there.

You’ve mentioned Release 5.5 is in planning - Is there an intention to move to a 5.5 release sooner ?

It’s not set in stone. The idea is basically that since we decided to timebox 5.4 meaning which means instead of waiting to finish a set of features, we said we’ll do as many of them as we can let’s say by early spring right and release that. After that, we start working on the next set of big features, which will be 5.5 and again we’d hope that it’s not going to be any later than like, let’s say, late next year all things allowing. I mean unless something drastic happens. In the meantime if there are contributions that should be pushed out or bug fix releases required. We might have A 5.4.1+ , but the idea is that we will start planning for a 5.5 right away and it might be that we set up another project plan for 5.4.1 if we decide that there are things that need to go out faster.

Right, but 5.4 was about some necessary breaks in backward compatibility, will 5.5 also focus on those sort of changes ?

No the expectation would be the same. I mean there are things that potentially would require a breaking backwards compatibility that probably can’t happen within this timeframe and if we manage to avoid those backwards compatibility breaks, and it might be a huge feature release, but it wouldn’t get the 5.5 tag. There hasn’t been any decision to change that naming convention.

On the topic of backwards compatibility, and this is up in the air because I proposed a Jeremy last week, and I need to make an issue for it so the community can discuss it and I haven’t had the time yet. I am proposing that we change our backwards compatibility policy. So you know in the past our policy has been that we try to make sure that any code written for TiddlyWiki whether it’s Wikitext, whether it’s JavaScript continues to work. Yes it did. And I’m suggesting that we change that and revise it to a commitment to trying to make sure that Wikitext works as it previously does, but there can be changes on the JavaScript front, which we will announce in advance. Give people enough lead time to upgrade their plugins and the idea there being that, it is really the end users who would struggle when Wikitext stops working as it does. Developers who write JavaScript plugins are more used to having to update their code. If we’re having to get them to update their plugin once every two years, that’s still far less frequent than any other open source project I know of that’s active. And then we would, you know, provide guidance on what the changes need to be. There is also the intention after 5.4 to try to set up a community plugin library, which has been talked about, to death, but we have an idea for how to get a minimal version of that up and running. Which would help us also be able to better understand what plugins are going to break when we change something on the JavaScript end.

And part of that is also that you know the break and JavaScript backwards compatibility already happens. And often we don’t manage to catch it because it’s just so difficult because what we haven’t done in the title Wiki core is mapped out a specific set of functions that are supposed to be publicly used by developers. Instead you can use anything, but very often we need to refactor and change those methods to be able to have new functionality. So those brakes happen anyway unintentionally. So rather than have these accidental breaks that we then have to rush and try to fix somehow and adds a lot of complexity. The idea is no let’s do it in an intentional controlled manner where necessary with enough lead time warning to everyone.

Lastly - You mention end users. What do you use TiddlyWiki for as a end user ?

Oh - You know I was very active in the community during the TiddlyWiki classic days and during that time most of my TiddlyWiki usage will actually all of it was not for myself. I didn’t use it myself at all. It was used entirely in educational context. I was creating tools for some of the schools, I was working with. I was working with a few professors in different universities prototyping different ways for providing slides and classroom and lecture notes to students and this was all public back in the TiddlyWiki classic days. The nice thing about TiddlyWiki 5 is that I actually had stepped away from TiddlyWiki for some years and I came back. And it was driven actually by my own personal needs to start off with so. The wiki that I use every single day is a note taking wiki. It doesn’t look anything like that normal TiddlyWiki interface. I did a demo of it, with a video with Jeremy some years ago, and I can send you a screenshot later if you’d like, but it’s actually a replicates an app on macOS called Notional Velocity. There are clones of it for windows, as well. So you have a text box. You can type into it to search, for a no title if it doesn’t exist, you can hit enter to create it and just start typing right away. So that is something that is constantly open somewhere on my desktop every single day and I use it every single day.

I maintain a few additions for a few groups of friend. So some of my interests include both natural wine, and also high-end Chinese tea , which is meant to be aged. So I maintain two additions that are for tasting notes and I have a small group of friends that uses both of them. It has its own update mechanism, so I can push out updates, and they get the new features and you can see each other’s notes. So that’s been quite enjoyable to actually make something for yourself that way.

I work with a few social workers in Central Asia right now, for whom I’ve made some reporting tools. These are people who I work with on a professional capacity, but the TiddlyWiki tools I made for them were on a volunteer basis. So it’s just I saw an opportunity to help out. There’s no budget, okay I’ll just go ahead and do it. So it allows them to take case notes while they’re in the field, and then be able to synchronize them back to a central server when they’re back at the office because they don’t always have field connectivity. So and, you know, TiddlyWiki is a great fit for that because of the fact that it’s truly offline first. There are very few tools that really are able to work just on your device with no internet connectivity. All other tools that even say they’re offline first, seem to almost have the offline feature just added on and it doesn’t work as smoothly, so that’s another use case.

So things like that, and I have I operate this site on GitHub that I call my Plugins Sandbox and everything on there is labelled experimental where I’ve been publishing components, a lot of the components, of this stuff and that’s because I don’t really have the time to be able to publish them as plugins with proper documentation, provide support, but the hope is that if I just put out what I can in terms of components will be helpful to someone.