Issue Porting

[meichthys]

How do we want to handle / migrate old Trilium issues? Does anyone have experience with this? Is it even possible to migrate the issues automatically (and would we even want to?)

Update

We are tracking the progress of porting issues/feature requests here:
https://github.com/orgs/TriliumNext/projects/1

If you would like to help out with this project, you will need to be a member of the "Issue Triaging" team.

[j-tirelli]

I think there is value in this, it's our best source of feature requests, bug reports, etc..

Preliminary googling says it's possible, maybe even with in-built tools on github

[eliandoran]

@meichthys , @j-tirelli ,

I've thought a bit about this when first creating the org. The question is... do we really need to port them?

There are currently:

1. 304 bugs
2. 408 feature requests
3. 258 bugs / feature requests / questions (uncategorized)

Copying the issues would:

• Cause confusion for the one who created the issue, seeing that it has been copied in another repo (under the name of a bot, most likely).
• Cause duplication between upstream and here, making it difficult to track which features/bugs have been fixed and where.
• Make it difficult for us to triage our own work, where we can use issues to track tasks and see bugs that present only on our fork (e.g. conversion issues).

What I think would be the best approach is to actually help @zadam clean up a bit the issues on his repository, as follows:

• For bug reports, we can have fixes done on our repo and optionally backported upstream. In our commits & PRs we can reference issues from zadam's repo just as well.
• For feature requests, if we manage to implement them and deliver them, mark the issue as won't fix on @zadam 's repo (since it's in maintenance) and redirect to ours.

Let me know your thoughts.

[j-tirelli]

I think this makes sense.

[meichthys]

Ok, i can get on board with this, but i think we will still get lots of 'duplication between upstream and here' when people file new issues here that already exist on upstream, but at least with this method, we know the issues here are relevant to us. We can decide to address this as those issues come in (Either triage to find related upstream issue, or just let the new issue stand on it's own).

[ProfDoof]

So, I made an issue related to this by accident as I hadn't seen this already. Here's my thought process:

1. zadam's repo is in maintenance mode so the only things we should be possibly be contributing back is bug fixes but realistically, that may introduce far more difficulty as we diverge further from the original code base so it might not be best to try to track them through zadam's repo.
2. There's a non-zero possibility that some feature requests likely fall under a broader umbrella of a feature such as "Switch to X editor" which would then allow for plugins or us to support those features and we should likely group them up and then knock them out that way.
3. You're right that it would make it difficult to track them if they were duplicated so it might be best to coordinate with zadam to transfer the feature requests to this repo so that they are centralized.
4. Bug reports maybe should be copied to this repository as they could be repaired in either place and maybe should be repaired in both places but tracking where they are fixed and where they aren't probably means that having them only on zadam's repo will make it more difficult.

So, my suggestion would be to go through the bug reports, feature requests, and questions, and organize them.

• Features should be organized into umbrella features that either summarize how an umbrella feature address that feature or adds future support for that feature through the use of plugins, themes, etc. (Basically a simplified design document of some kind)
• Bug reports should be organized into things that can be addressed during different phases of the current refactoring process or things that need to be considered later or even things that would be addressed by simply implementing a different feature. (Such as switching from ckeditor to a different editor with better support for some thing that is needed to fix the bug)
• Questions should probably be answered on zadam's repository (if someone knows the answer) and possibly added to an FAQ if they are seen repeatedly.

Also, this reminds me, but we should probably add an issue for either replicating the wiki or providing a docs site for the same stuff.

[CrO2Cl2]

Sounds great, will start to look through the feature requests and start to aggregate them, how should we communicate? Should we just make another room on matrix and talk through there?

[meichthys]

I've created a Project here: https://github.com/orgs/TriliumNext/projects/1

@CrO2Cl2 Is there a trilium matrix?

[CrO2Cl2]

afaik we settled on using the matrix room in this discussion

[meichthys]

Ah yes, that droped off my radar. That works for me. We can break out into a Thread if we don't want to clutter up the main chat.

[maphew]

...we should probably add an issue for either replicating the wiki or providing a docs site for the same stuff.

I was about to act on this and create an issue, but my thoughts aren't well formulated yet, and issues are best kept to things that can be opened and closed. So a discussion thread instead: #62 Trilium hosted wiki?

[meichthys]

I've created a project here we can use to track our progress of porting issues: https://github.com/orgs/TriliumNext/projects/1

[meichthys]

@meichthys , I think we should not bother @zadam with asking him to transfer the issues on his own.

I wasn't expecting zadam to do the transfers himself. I only was waiting since zadam thought it would be helpful to him if we transfered them out (perhaps less issues to search through). If we had owner permission for an hour or so, we should be able to do the transfer ourselves. It would probably be a more seamless experience for the original feature-request reporters if they saw their issue migrated to our repo - that way they would be able to follow the issue and they would realize that future development of feature-requests would be happening on TriliumNext. Closing the issue isn't a bad solution, but it does obscure the original reports from our view (unless we manually copy over the text of the feature requests or rely on links).

All that being said, I'm fine with moving forward with manually recreating the feature requests in our repo (converting our existing project 'draft issues' into actual issues).

[eliandoran]

@meichthys , I've thought about temporary access as well and did discuss this with zadam but it does not seem to be possible for personal repos, only within an organization.

Case in which we're stuck either with a script of some kind to automate the process or manually doing it.

https://stackoverflow.com/questions/64478636/how-to-give-admin-access-to-private-repository-when-there-is-no-role-options

[meichthys]

Ah.. ok. in that case, let's get this thing moving!
I'll get started today in converting our existing 'draft' feature request categories over to issues. Where relevant, i'll copy over the text from the best feature request on the original repo.

Once the manual 'transfers' are complete, I'll go ahead and close out the issue on Trilium.

[eliandoran]

@meichthys , sounds great.
I've created a label called ported-issues which we could assign to the new issues in order to be able to easily identify them from our own issues.

[meichthys]

Good idea. Will do 👍

[CrO2Cl2]

I have finished aggregating all the issues to the Project

[meichthys]

Wow great work!
I will review soon 👍