A Little Github help please

[TonyM]

Folks,

I have mastered the mechanism to submit changes to tiddlywiki.com because of the pink bar

 Can you help us improve this documentation? Find out how to edit this tiddler on GitHub

Contributing to the core on some fairly simple changes is my next desire.

I have looked at other Tiddlywiki/Github doco and they are little to "general" and still contain jargon, hence these questions.

I need just a little help.

• I forked the master and submitted a change more than a year ago
• This is the only time I got recognised on a release
• A little sad given my non github work, seem only changes to gihub core do this.
• Can I just propose changes via that same fork?
• Do I need to refresh the fork with the current version?
• Can I use the GitHub for desktop?
• Is it sufficient to raise an issue and propose a commit, even if it is initially rejected because of a naming standard or something more serious? 
• I find it hard to get a well developed concept taken seriously in the issue thread, and who would give me the go ahead anyway?, it seems I just need to jump into the deep end and submit changes? 
• What about a mass change that has a minor possibility of conflict?
• I would like to propose a change to all existing buttons (#4272)
• However there is a slight overlap with other proposed changes in the above issue including converting "widgets to actions"
• How do I discuss this such as with Jeremy who was proposing a related change, and has already done his change for new Journal/tiddler buttons

I so wish to contribute more, but I need to takes a few more steps.

Regards

Tony

[PMario]

On Friday, July 10, 2020 at 2:36:21 AM UTC+2, TonyM wrote:

...

I have mastered the mechanism to submit changes to tiddlywiki.com because of the pink bar

 Can you help us improve this documentation? Find out how to edit this tiddler on GitHub

Did you watch all 3 videos? ... Most answers should be there.

 

I need just a little help.

• I forked the master and submitted a change more than a year ago
• This is the only time I got recognised on a release
• A little sad given my non github work, seem only changes to gihub core do this.
• Can I just propose changes via that same fork?

Yes. ... If you start editing from Jeremy's "master" or "tiddlywiki-com" branch as shown in video 3.

 

• Do I need to refresh the fork with the current version?

Not necessarily. If you start from Jeremy's repo/branch you will get an updated "feature branch" in your repo.

 

• Can I use the GitHub for desktop?

I personally would say. Use something else.

I did install it years ago and it had the worst user experience that I've ever seen. So may be it's time for a new test.

• Is it sufficient to raise an issue and propose a commit, even if it is initially rejected because of a naming standard or something more serious? 
• I find it hard to get a well developed concept taken seriously in the issue thread, and who would give me the go ahead anyway?, it seems I just need to jump into the deep end and submit changes? 

Creating issues is "kind of" sufficient. ... BUT you have to find someone, who actually implements the pull request. ... So PRs have a much bigger chance, to be merged. Especially for the tiddlywiki-com branch, which is the documentation branch. ... So DOCS only!

• What about a mass change that has a minor possibility of conflict?
• I would like to propose a change to all existing buttons (#4272)

That's a rather big one. ... So chances are high, that there will be some discussion. ... If the discussion is controversial it may need more than 1 PR cycle.

So you should start with a "POC" proof of concept.

eg: 1 working button for every "toolbar" you want to change.

eg: 1 button in ViewTemplate, 1 in EditTemplate, 1 in right sidebar ... If that's what you want.

+ Doc changes for at least 1 button ... So we can see, how the new docs would look like. Getting the docs right is probably much more work than changing the code.

May be new config tab in ControlPanel .. if needed.

I think, this would be the minimum amount of work, you'll need to put into the PR, to test if it would be merged. ... There is nothing more frustrating, than creating a PR which needed weeks to be built, which gets rejected. ... But that happens! ...

So going with a POC has a high chance to start a discussion. You get feedback before you put too much work into it. Those discussion may lead to a completely different solution, than you may have envisioned. .. And it may take longer, than you wanted. ...

But in the end

There is 1 very important hurdle you have to pass. ... Whatever lands in the core will be there "forever" and it has to be maintained "forever". ... Hopefully it's you that cares about this functions and you maintain them. But if not someone else has to do "care take care".

• However there is a slight overlap with other proposed changes in the above issue including converting "widgets to actions"

Overlap with proposed changes is _no_ big problem. ... Overlap with existing PRs IS!. .. So if your changes cause conflicts with other "new" PRs, you should be careful. ... If the other PRs are older than a year and still open. Go on with your PR. .. Others can make new PR if necessary.

• How do I discuss this such as with Jeremy who was proposing a related change, and has already done his change for new Journal/tiddler buttons

If the changes are already implemented in "master branch" you just use them. ... Starting from Jeremy's master. 

 

I so wish to contribute more, but I need to takes a few more steps.

If this info isn't enough. .. Please tell. We will make it work.

I know, the Videos are 6 Years old and the github UI has changed quite a bit. ... But the concept is still the same.

@all

If you think, the videos are already uselessly old, please tell. ... There is always room for improvements.

have fun!

mario

[PMario]

Hi Tony, 

I did also create a video series, how I did set up my own TW development environment. ...

I'm using the "brackets" editor, because I like it. ... There are other editors available. ... The plugins used to integrate with git and github are different for every one of them. ... BUT the underlying workflow is the same for _all_ of them.

See: How to work with a TiddlyWiki development environment

-mario

[PMario]

On Friday, July 10, 2020 at 2:36:21 AM UTC+2, TonyM wrote:

..

Can I use the GitHub for desktop?

As I wrote ... I'd go with "your favorite" editor / plugin "bundle". ... Those setups will work for every git-hosting implementation.

GH-Desktop is meant to "bind" you to a GitHub only solution, which for me is a no go. ... But that's just me ;)

-m

[TonyM]

Mario,

Thanks so much, I will focus on becoming a Git contributor, the key reassurance is a prior fork remains up to date, as I would have expected. I did not want to submit changes to an old copy.

Some small Questions

• It it acceptable for me to make changes in the forked repository using the GitHub interface rather than using a separate editor?
• Is my POC just a wiki with the changes included?
• In this case I can see a way to just make a package that overwrites the core tiddlers as the poc, and share a single-file wiki as the POC

As I understand it then;

• In the overlapping issue I can redesign the current change (already committed) on three buttons to make them comply with the new approach applied to the remainder of buttons. This would become part of my change request then, part that can be rejected.
• Specifically adding the actions=parameter to buttons
• In this case actions={{transclusion}}

The bigger question

• Are you assuming that when I make some changes I do it in my own fork and build a tiddlywiki from that?
• Or can I make changes to a separate wiki for the POC and only submit changes once I have support?

In this case I want to introduce a features that no one will notice until they want to customise or hack tiddlywiki further. Hopefully this is a good one for me to have my first go because as long as there are no design errors the change should be repetitively invisible.

Thanks again

Regards

Tony/TW Tones

[PMario]

On Friday, July 10, 2020 at 9:58:25 AM UTC+2, TonyM wrote:

Thanks so much, I will focus on becoming a Git contributor, the key reassurance is a prior fork remains up to date, as I would have expected. I did not want to submit changes to an old copy.

Important: If you start from your own repo, you'll start with a potentially outdated version. .. Always start editing from Jeremolene/TiddlyWiki5

 

Some small Questions

• It it acceptable for me to make changes in the forked repository using the GitHub interface rather than using a separate editor?

Yes. As above. Start "Editing" files from the Jermolene/ repo. Then a new and actual feature branch will be created in _your_ repo. .. After you made a PR, you can add to this PR/branch until it is merged. ... If a PR is merged, a _new_ feature branch will be needed.

I did show this particular workflow in the first 3 videos.

 

• Is my POC just a wiki with the changes included?
• In this case I can see a way to just make a package that overwrites the core tiddlers as the poc, and share a single-file wiki as the POC

That's also possible. ... ZIP the file and you can add it with drag and drop to an issue.

 

As I understand it then;

• In the overlapping issue I can redesign the current change (already committed) on three buttons to make them comply with the new approach applied to the remainder of buttons. This would become part of my change request then, part that can be rejected.
• Specifically adding the actions=parameter to buttons
• In this case actions={{transclusion}}

I'm not sure, if I understand the question. If a PR is merged, it can't be modified anymore.

PRs are accepted or rejected as whole. Jeremy doesn't do an "cherry picking".

 

The bigger question

• Are you assuming that when I make some changes I do it in my own fork and build a tiddlywiki from that?

That would be the standard development workflow. I usually have 2-3 feature branches, that are similar but not the same.

eg:

 - At first I do implement a new feature, in the way I think it makes sense.

 - Once it works .. I usually, immediately have new improvements in mind.

 - Sometimes those "improvements" completely ruin the work already done.

 - That's why it make sense to create a "feature-x" branch based on "master" ... The one that worked as intended ;)

 - Then I create a "feature-x-large" branch based on "feature-x".

 - So if x-large goes "haywire" it can be replaced with feature-x again.

• Or can I make changes to a separate wiki for the POC and only submit changes once I have support?

It's possible to create a single file wiki and discuss this one. tiddlyspot will also work well eg: I did create 4460-dod-tiddlyspot.com/ to discuss something. #4460 is the issue number at github. This makes it easy to keep track of them. Once the Issue is fixed or the PR is merged, the wiki can be removed.

 

In this case I want to introduce a features that no one will notice until they want to customise or hack tiddlywiki further. Hopefully this is a good one for me to have my first go because as long as there are no design errors the change should be repetitively invisible.

If you talk about #4472, you already got a "looks promising" from Jeremy, which is a good start :) ... But the usual "candidates" didn't join the discussion yet. .. except Mat and myself.

So don't be afraid, if more than 1 iteration is needed.

-mario