When and how to promote Task Coach v2 and also transfer old issues?

[wolftune]

For @realcarbonneau especially but anyone can discuss: how soon does it make sense to start going through all the old SourceForge tickets and telling people that development is continuing here, that people can try the new versions and report issues here, and so on?

My thinking is finish going through the old issues, inviting the transition, opening new GitHub issues for outstanding specific bugs and requests, and close the SourceForge issues. Then, after that, we can move on to getting Jerome to update the website…

[realcarbonneau]

I would start by showing signs of life and announcing early alpha versions as alot of things that we don't use regularly but that others have used in the past, might be broken. Alot of users might also have moved on to other task managers. Possibly put a link from the taskcoach.org to the github page.

For example, the twitter/x feed is dead, even though some people asked for news on the project. There are still 488 twitter followers of the taskcoach project. It doesn't really matter if we like x/github/MS, etc or not, if you want to reach users, using these platforms might be necessary.

If you want to also have a non-commercial platform opensource presence, we could have a mastodon/fediverse account. But at the same time, multiple platforms, plus the website, etc. makes more work and might confuse users.

Do you have access to the taskcoach.org emails? The twitter account? etc?

[wolftune]

Again, I was thinking to go one-at-a-time through the things we already have individual connections for in the SourceForge tickets. Then, after some of those users respond, and we fix bugs etc, then we start showing the more general public life signs.

I don't have access to the X account. I do get the forwards from the taskcoach.org emails. I don't have access to the website.

I'll email Jerome right now and see what comes of that as the next step

[realcarbonneau]

It's really up to you. I understood your first question, and I am aware of all the open bugs. My answer was from a debugging and development perspective. For example, if you go down the list of old issues, and the next one is someone that had a past problem on windows, we don't even have a running build on windows we both don't use windows. So you might be saying that we can look into this bug, but we don't even know how far we are from having a windows build.

But from a promotion perspective, you can ask if they are still willing to test and be involved, etc. That is a different angle which also includes managing expectations and workload.

Also, just trying to be helpful, maybe start by targeting the users that you feel were previous long time users that might still be willing to participate and that are probably on the main linux distros and that probably use mostly the same features we do.

But that is really up to you and what you feel might be productive.

To answer your question specifically (in case my above answers are too general and vague):

How soon does it make sense to start going through all the old SourceForge tickets and telling people that development is continuing here, that people can try the new versions and report issues here, and so on?

For users on the main linux distros that use the basic functionalities that we use, you can start now.

[wolftune]

I went through all the old SourceForge tickets and processed the Linux ones.

As any action on a ticket might email people involved, I figured that closing the Linux ones with a reference to this GitHub repo would be appropriate. I moved some that I tested as still relevant into the issues here. Most I closed with an appropriate message.

I didn't even look at the ones marked MacOS or Windows. Some of those might not be OS-specific, but acting on them could get attention from MacOS or Windows users. So, I figure we can wait until there's a MacOS or Windows package worth testing. We have enough to do anyway, not looking for tasks to fill time.

There are other feature-requests and things to get into, but I think this was enough of a step for now

[wolftune]

I started transferring old UserVoice requests. I am selecting relatively trivial ones first. I'm deleting from the old list anything totally outdated or worth simply rejecting. I am waiting for later to add any significant items that would require more work and design discussion and so on.

[realcarbonneau]

Windows version is now building and running. See

v2.0.1.1 - Windows Build Updates and Fixes
https://github.com/taskcoach/taskcoach/releases/tag/v2.0.1.1

However, in doing this, I found that the whole date/time system needs to be refactored to have the code run seamlessly on windows, linux, macOS, etc. The current workaround should be fine for now, but the work needed to be done is noted in:

TODO - Datetime and Timezone Refactoring
https://github.com/taskcoach/taskcoach/blob/master/docs/TODO.md#datetime-and-timezone-refactoring

[wolftune]

@realcarbonneau superb! (For Task Coach, and practically for a bunch of Windows Task Coach users; though I don't like that Windows is what it is in the world)

I have not followed it, but isn't Windows today something like Apple wherein Microsoft makes it weird for people to just get software from wherever? Like is their some signing or override of security settings or something else that we need to document for users to do these days aside from just install a build downloaded from GitHub?

I will go ahead and transfer over issues from Windows users (of those that might still be relevant) and otherwise announce this for people to test once you say that things are worth more people testing and we have documented whatever people need to know about installing and running the updated software

[realcarbonneau]

@wolftune

is their some signing or override of security settings or something else that we need to document for users to do these days aside from just install a build downloaded from GitHub?

Yes, they have to accept a security exception, something to the effect that the downloaded software is not trusted. But if anyone actually tries and get's stuck at that, we can answer/document at that time.

I also don't want to spend time on Windows, so now that it runs, I rather just let users post issues of what they find.

[wolftune]

Okay, so not add something to the README? I think saying there that installing requires a security exception or linking to some article (surely someone somewhere has summarized the situation for cases like ours…) could make sense

So, my situation here about Windows users is like this: any Windows user who posted any bug at SourceForge would get notified if I take any action on their ticket. So, I avoided doing anything with Windows tickets, even when the issues were completely within Task Coach and I can already reproduce myself on Linux. Now that Windows builds exist, I can go through those and just close outdated ones, open issues if really worthwhile, etc. And whatever the action per ticket, I will be telling people that they can come and get the update, so at least in that context, I'm inclined to tell them that a security exception is needed, and I'd like to do so in the most appropriate way (appropriately critical of the dynamic, appropriately charitable, and balancing our non-liability with the goal of not scaring anyone)

[realcarbonneau]

@wolftune

I'm inclined to tell them that a security exception is needed.

I just added screenshots and screen recording here, if you want to use them. This is for Windows 10, which is a good reference for technical testing, like I needed to do, but I have not idea how the new versions react for software download, probably something similar.

https://github.com/taskcoach/taskcoach/tree/master/test%20screenshots
https://github.com/taskcoach/taskcoach/blob/master/test%20screenshots/MS%20Windows%20Install%20-%20Security%20Warning%20-%20Screen%20Recording.gif
https://github.com/taskcoach/taskcoach/blob/master/test%20screenshots/MS%20Windows%20Install%20-%20Security%20Warning%20-%20Screenshot%201.png
https://github.com/taskcoach/taskcoach/blob/master/test%20screenshots/MS%20Windows%20Install%20-%20Security%20Warning%20-%20Screenshot%202.png

[wolftune]

I just mentioned the issue, the style of my post is (a few minor variants):

Hi, it's over 13 years later! I'm closing old tickets and announcing that Task Coach is now updated to Python3 and development is finally active again, thanks to new volunteers. The project has now moved to https://github.com/taskcoach/taskcoach

I'm using it myself, and things are working better than ever. Packages are available for some common Linux systems and for Windows (note that it isn't recognized by Windows Smartscreen but can be installed by accepting the warning anyway)

We'd love to have you test the updated program, and post any issues that arise there at GitHub

We won't be continuing with SourceForge, just clearing out old issues and letting people know about the move

Cheers

I have now closed all the "support requests" at Sourceforge except the MacOS ones (will wait to close those and get those users' attention until we have a MacOS build). Very few had anything worth moving into an issue right away. Next is closing the "bugs" at SF.

[wolftune]

@realcarbonneau unfortunately, at https://github.com/taskcoach/taskcoach/releases (not the link to any specific release), there are now so many assets that I had to click "Show all 15 assets" to reveal the Ubuntu .deb packages

[realcarbonneau]

@wolftune

@realcarbonneau unfortunately, at https://github.com/taskcoach/taskcoach/releases (not the link to any specific release), there are now so many assets that I had to click "Show all 15 assets" to reveal the Ubuntu .deb packages

That's a good point, I guess I just took that for granted, but may be confusing for occasional github users. There aren't any good solutions, there is no favorite option for this. We can drop some builds if there is no interest. It's just good to have them all because it makes sure that any changes compiles and passes basics tests for all target platforms.

[wolftune]

Yeah, it's too bad; I wish we could at least order the items. I would do things like put the Ubuntu 24.04 in the top of the list and the 22.04 further down etc. but at least the direct links to each release don't seem to have this problem.

[realcarbonneau]

@wolftune

there are now so many assets that

I reduced the number of builds to the most common ones for now and removed redundant ones.

v2.0.1.6 - Builds Cleanup
https://github.com/taskcoach/taskcoach/releases/tag/v2.0.1.6

[realcarbonneau]

On the topic of issue organization, we should have a label for each of the main functionalities of taskcoach, so it's easier to get an overview of all issues/requests for a features. Eg. I added categories and manual ordering. As the need comes up, feel free to add Effort, Notes, Calendar, Sync, Email, etcs

[realcarbonneau]

Because we have alot of issues now, please put the label "Active User" on issues that you feel current users are being blocked by or inconvenienced by. I will prioritize these first. @wolftune

[wolftune]

While that makes sense, the practical matter is that "moved from" in the title pretty much means that we have no verification of someone being an active user until that person replies. I moved issues mostly after confirming that they remain unresolved and did not seem like things we probably want to ignore (so, I didn't move some requests like wanting week to start on any weekday or specific calendar-view issues or other things I don't know that anyone cares about). Everything I moved over just seemed to me something worth still noting as an issue (but that doesn't mean they are all high priority!)

I have some particular issues I want updated but I have been waiting to post them until I have the sense that the codebase is relatively cleaned up, things are using new-enough libraries, and we've resolved awkward bugs that would irritate or turn-off anyone trying TC.

I was thinking about whether we would like having a prioritization method here. Some way to indicate someday/maybe issues vs priority bugs etc.

[realcarbonneau]

@wolftune

matter is that "moved from" in the title pretty much

Yes, that information is in the title, but searching by keywords is not great quickly organizing the issues in flexible ways. That is why I added all the tags and extensively use them. We could also put a Legacy tag, but there isn't a way to exclude tags, so it's easier to tag things as Active, versus tagging things as legacy. (Tag = Label)

Tagging the issues helps decide the priority. If I am working on an issue, let's say Efforts, it efficient to have a view of all the Effort related issues/requests, because it can help direct various Effort related design decisions that might be required to fix a bug. When deciding the next issue to work on, I will usually only look at Active user issues. So it's not just a question of simple priority of issues.

Just sharing my current work process with the issues, of course you can work with the issues and discussions and make priority lists in whatever way you feel best also.

Feel free to add any issues you want, often I will add a issue as soon as it pops up, with proper tags, so that I have traceability and see it when I work on that functional area at a later date.

[wolftune]

Overall I really appreciate your methods of clearly marking things and everything else about how you are managing issues here.

Interestingly enough, one of the main features I'm personally most eager for in Task Coach (but waiting for the rest of the noise to be settled enough) is the ability to filter OUT by category. I have notes about how this design could work, how to have a NOT function for category filtering rather than only AND or OR.

GitLab actually has the ability to do NOT, to filter out by tags. I was hoping GitHub would too, but indeed the documentation indicates the feature is missing. Because of this, we are indeed limited to tagging for things we want to see and can't tag things that we want to filter out.

As for my personal most-wanted features that I've hung on to all these years, I will get around to adding them. I won't keep them secret or anything, but even though they are relatively simple, they require some actual design discussion and consideration. I think they will go best once we sort of have the project in place cleanly enough with no major issues and a good method for organizing issues and project-management.

[realcarbonneau]

macOS build
#206 (comment)

[wolftune]

w00t! Maybe we should make two files separate from the README that explain the security exception issues for MacOS and Windows. We could clarify in text there, offer some link if we can find one to a good explanation of the issues (both fair and recognizing conflict of interest and conflicts with software-freedom) so we aren't wasting time writing our own, and include screenshots there. Then, we could link to those documents from the README with new sections for installing for Windows and MacOS.

If you agree, let's open a documentation issue with these ideas (you could assign to me if you like, though if you feel like doing the actual work, I won't mind)

I think best to get MacOS listed in the builds in the README, add these files and links, and then it will be good for me to alert MacOS users to test…

[realcarbonneau]

Ok, I am working on a first draft now.

[realcarbonneau]

@wolftune

README is updated with short mac and windows with links to detailed readme docs with screenshots for each.

https://github.com/taskcoach/taskcoach/blob/master/README.md
https://github.com/taskcoach/taskcoach/blob/master/README_INSTALL_MACOS.md
https://github.com/taskcoach/taskcoach/blob/master/README_INSTALL_WINDOWS.md

[wolftune]

my one concern about an otherwise amazingly quick drafting (are you using AI to do some of this??) is the bit "The software is safe" which sounds a bit too much like a warrantee, an assertion implying accepting liability. I think we should instead say "The safety and security of this software can be verified by:"

[realcarbonneau]

my one concern about an otherwise amazingly quick drafting (are you using AI to do some of this??) is the bit "The software is safe" which sounds a bit too much like a warrantee, an assertion implying accepting liability. I think we should instead say "The safety and security of this software can be verified by:"

Yes, partial AI, but I type stuff too, like this ;) Yes, that line is totally an AI bullshit line, haha, I really don't want to spend alot of time on Windows/Mac stuff. Alot of the time, like if we say "the bug is fixed, the backup is working" and it's not and it deletes user data, there are no warranties regardless of what we say. But I will change it be less like "trust me bro, it's perfectly safe!"...

[wolftune]

FYI, there are as of this writing 662 requests from the UserVoice export that I have not opened issues for. I am bringing up some when the topic arises for other reasons. I went through and opened issues for the most obvious and important ones that seem likely in-scope. Many are totally out of scope, some are confused, some are nice but low-priority, some are incompatible. I don't have the vote-count or the follow-up comments unfortunately. In past years when we did use UserVoice, I regularly closed and consolidated issues to reduce the bulk…

My plan is to eventually get through all of them, just ignoring ones that are not worth mentioning, opening issues as appropriate otherwise.

And when something marked "moved from UV" is completed I'll specifically check whether we have an email for the requester to tell them it is fixed (we don't have emails for all of them).

And regardless, when we get to an even better point with the program overall and hopefully an updated main website and such, I could eventually just do one bulk announcement to every email we have from the UserVoice request set. Similarly, I can email everyone who opened a bug or support in SourceForge even if they were closed before recently (I have only done actions on tickets that were open). That is my thinking about future one-time announcement to help more people realize that the update is available.

[wolftune]

One bit of great news: https://sourceforge.net/projects/taskcoach/ is now successfully loading the GitHub releases and anyone downloading from SourceForge is actually getting the updated GitHub releases. There's also a link saying that the project moved to GitHub. Anyone following the SourceForge project ought to have been notified, though I'm not sure that happened as I haven't myself seen any such notifications…