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
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywikidev/44cfd19a-fe2b-4dbb-86bd-3bf4b797e9e3o%40googlegroups.com.
