Open Jermolene opened 2 years ago
I did create tiddlywiki-org organization, so nobody else can register it.
I also used it to have a playground at github, to see, how organizations can be configured.
I personally wouldn't delete that organization, because then anyone else can misuse it. .. And it could still be used if we need a place to run experiments.
I can remove all the visible content and only show some links to the TiddlyWiki organization.
I did create tiddlywiki-org organization, so nobody else can register it.
Equally, we can't preregister all the possible TiddlyWiki-related organisation names. I don't think it's a problem to let it go.
I personally wouldn't delete that organization, because then anyone else can misuse it. .. And it could still be used if we need a place to run experiments.
I don't think that's sufficient. Just having it turn up in search results is deeply confusing for end users. If you want an org to experiment with then I think it should be renamed, or create a new one.
OK. So you definitely want tiddlywiki-org to be deleted. right?
I also created TiddlyWikiClassic ... So you definitely want that to be deleted too. right?
Thanks @pmario, yes please, much appreciated.
I did remove them. The names are locked for 90 days now
Thanks @pmario – of course it's the migrations that are going to take a little longer :smile:
I've just transferred TiddlyDesktop to https://github.com/TiddlyWiki/TiddlyDesktop. Everything should redirect transparently. If things go smoothly I'll move ahead with the other transfers.
I've opened some tickets on the TiddlyWiki repo:
What can be in the TiddlyWiki organization?
We have nodejs wiki app and automated plguin library in https://github.com/tiddly-gittly , but they are mostly around TidGi (make most things work out-of-box for new users). Maybe they should just be in tiddly-gittly until some conditions meet?
I think using an organization other than a single repo, we will have the opportunity to move official plugins to separate repos, I think it will be easier to manage issues for each plugin.
And maybe even refactor the core parts of tw, so they can be used in a "headless" way, for example, a browser extension that renders readme.tid in the Github. This will make TiddlyWiki not "zero dependencies" anymore, so may not be a good idea.
Hi @linonetwo
What can be in the TiddlyWiki organization?
The main TiddlyWiki organisation is to codify community ownership of the offical distribution of TiddlyWiki and the associated tools. So there are two criteria:
At this point, it's probably still going to be a judgement call in individual cases.
We have nodejs wiki app and automated plguin library in https://github.com/tiddly-gittly , but they are mostly around TidGi (make most things work out-of-box for new users). Maybe they should just be in tiddly-gittly until some conditions meet?
We're 25% of the way through 2022, and my big personal goal for the year is to get an official community plugin library up and running. TiddlyGittly is hugely encouraging and inspiring, and would be very similar to what I have in mind.
I think using an organization other than a single repo, we will have the opportunity to move official plugins to separate repos, I think it will be easier to manage issues for each plugin.
I'm committed to keeping the core distribution of TW5 in a single repository because it makes things so much easier for users – there can be no confusion about whether two given components have matching versions, because the repo as a whole is versioned.
Currently, there are too many irrelevant and obsolete plugins in the TW5 repo. Once the CPL is up and running, I'd like to move things like the D3 plugin out of the core. The plugins in the TW5 repo should just be the key plugins with community ownership (eg the Markdown plugin).
And maybe even refactor the core parts of tw, so they can be used in a "headless" way, for example, a browser extension that renders readme.tid in the Github. This will make TiddlyWiki not "zero dependencies" anymore, so may not be a good idea.
I'm not sure what you mean – TW5 can already be run headless under Node.js?
I would like to introduce a mechanism for cleanly handling optional npm dependencies (eg the AWS plugin).
I would like to introduce a mechanism for cleanly handling optional npm dependencies (eg the AWS plugin).
I personally wouldn't want to add the npm dependency nightmare to tiddlywiki. From my point of view npm dependencies are a general security risk, for everyone who uses it.
I would like to introduce a mechanism for cleanly handling optional npm dependencies (eg the AWS plugin).
I personally wouldn't want to add the npm dependency nightmare to tiddlywiki. From my point of view npm dependencies are a general security risk, for everyone who uses it.
@pmario perhaps you misunderstand me. We already use npm dependencies. My point is that the AWS plugin currently requires users to manually type "npm install aws-sdk", and that I'd like to introduce a mechanism for Node.js plugins to declare optional npm dependencies that get managed by TiddlyWiki as required.
@pmario perhaps you misunderstand me.
I think, I didn't. ... but I'm OK with the idea, to use "minimal audited" tiddlywiki dependencies.
...My point is that the AWS plugin currently requires users to manually type "npm install aws-sdk", and that I'd like to introduce a mechanism for Node.js plugins to declare optional npm dependencies that get managed by TiddlyWiki as required.
I think that's a good thing and github supports these possibilities: https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-npm-registry and https://docs.github.com/en/packages/working-with-a-github-packages-registry
the AWS plugin currently requires users to manually type "npm install aws-sdk", and that I'd like to introduce a mechanism for Node.js plugins to declare optional npm dependencies that get managed by TiddlyWiki as required.
There are two ways, one is using my ts plugin template https://github.com/tiddly-gittly/TiddlyWiki-TS-Plugin-Template , which will pack all npm deps into the json plugin.
Another is run npm install
on the fly, this requires tw runtime bundle nodejs and npm withit (probably only tiddlydesktop and tidgi have this prerequisit), I have seen this in zazu app https://github.com/bayleeadamoss/zazu , it will run npm programmitcally for user using built-in npm and nodejs.
@linonetwo I think transpilers are part of the problem I want to avoid and not a solution.
Have a look at your dev-dependencies and tell me, that you can guarantee that you exactly know what you install and execute on your system. (With probably admin privileges)
Most of our users have absolutely no idea what those settings mean, and what they do if they run npm install
. I consider this a security problem that we should avoid at all cost.
Just search for npm supply chain attack for the last month and you'll see, what I mean.
I think, I didn't. ... but I'm OK with the idea, to use "minimal audited" tiddlywiki dependencies.
Who is suggesting anything different? It really seems like you have misunderstood. I made a casual reference to improving our existing usage of npm and then a few minutes later you're talking about npm supply chain attacks. Those kind of scare stories are pretty unhelpful here. Please be specific about what you think we're doing wrong, or about what specifically is wrong about my proposal.
We can deal with plugin security risk (including the risk introduced by the npm dependencies) by comment and rating system in CPL.
Core plugins are trustworthy, but those outside the organization and aggregated by the CPL will need this. We have setup the comment system using Discussion as comment storage in the example CPL, while rating is not implemented yet.
This is offtopic I think, we can discuss this elsewhere, acturally I have many thought oh this.
We can deal with plugin security risk (including the risk introduced by the npm dependencies) by comment and rating system in CPL.
The TW plugins are not the real problem. Installing the development system, that introduces a massive amount of dependencies is the problem, I'm talking about.
Please make sure issue, commit, pr, and discussions are mostly keeped during migration!
Searching in these materials always gives insights to me.
Hi @linonetwo yes indeed! As far as I can tell, the complete history of the repos is retained when they are moved. https://github.com/TiddlyWiki/TiddlyDesktop has already been moved, and seems fine.
Very good to have everything in one place. One comment with regards to the name TiddlyWikiClassic, abbreviated this would logically be TWC. TWC is not a wiki-word and ends with a prominent WC at the end. Would it be possible to use TiddlyWiki-classic or TiddlyWiki classic and abbreviate to TWc, TWc is a wikiword. A lowercase c just looks a little more classier than the uppercase C, but that is just my opinion.
Have a nice day, Okido
Over the years, a number of GitHub Organisations related to TiddlyWiki have been created by myself and others.
It is proposed to adopt a policy of moving all official TiddlyWiki-related repositories to the main https://github.com/TiddlyWiki organisation.
To keep the logistics simple this will be a gradual change.
The following repositories need to be migrated to https://github.com/TiddlyWiki:
I think the following organisations are experiments that can be deleted immediately:
UPDATE 31st April 2022: I've opened some tickets on the TiddlyWiki repo: