Added content for all tweets and retweets which have happened on ETH_Network since the automation started on September 8th.

[bobsummerwill]

Added content for all tweets and retweets which have happened on ETH_Network since the automation started on September 8th.

Various tweets and retweets had been made directly, outside of this automated workflow, meaning we had lost revision history here. When this is merged we will end up with some duplicates, but can tidy them up on the other side, getting us back into a clean state. Updated the examples and the README not to use eth_classic, because we are intentionally moving away from that. Removed TestRetweet, which should not have been committed. Removed "Why" tweet, because there was a "WhyClassic" at the exact same time. Duplicated.

Two of the reply tweets are missing images/GIFs versus the directly posted versions. Need to work out how to add those in.

[bobsummerwill]

@IstoraMandiri So the ChuckSRQ history there is a bit of a mess.

Are edits to existing "tweet" files not noticed by the automation?
So you had to keep making new filenames for them to be actioned?
Like - it is a one-shot deal on these files?

If so, we could at least deleted those two older versions out without any damage, to make it clearer.
But not rename, because that would trigger a fresh retweet.

(Aside - merging this will retweet/re-reply to everything, but then at least we have the history and can manually clean up on the other side).

And from there, try always to stick to the Github flow, for ease of papertrail.

[bobsummerwill]

@IstoraMandiri Just pushed a commit into this PR with those deletions.

[gitr0n1n]

@IstoraMandiri So the ChuckSRQ history there is a bit of a mess.

Are edits to existing "tweet" files not noticed by the automation? So you had to keep making new filenames for them to be actioned? Like - it is a one-shot deal on these files?

If so, we could at least deleted those two older versions out without any damage, to make it clearer. But not rename, because that would trigger a fresh retweet.

(Aside - merging this will retweet/re-reply to everything, but then at least we have the history and can manually clean up on the other side).

And from there, try always to stick to the Github flow, for ease of papertrail.

So @IstoraMandiri and anyone participating right now are learning the limitations of the Twitter Together code right now.

Centralization Right now:
There will likely be a lot of manual tweets by me until we figure the work arounds,
Example- we don't know how to add a picture to a tweet or delete a tweet.

So those tweets need me (centralized admin creds) to log in post them. right now. Please remember we are in early beta stage.

By the time I convert this account to a shared email (more decentralized ownership), we will have ironed out all these learning pains. So I don't think it is super important to focus on having a 100% accurate post history of every tweet in this repo right now, as I will be for sure logging in to tweet some more on this account during this process.

At the decentralization transfer, I think it makes sense to do this clean up though. So a good exercise, but lets not sweat the small stuff while we are in early beta trying to figure out the limitations of Twitter-Together and brain storm the work around of those limitations.

[IstoraMandiri]

Thanks for the comments Bob.

Yes, the twitter-together codebase is fairly limited / not tested, and we are using an experimental fork to enable rewteets that has proven quite fickle, but next week I hope to make some improvements to fix the rough edges.

It is very much experimental in code and social / contributions workflow.

Also, looks like a bunch has been merged upstream recently which I'll need to check out. https://github.com/twitter-together/action/pulls?q=is%3Apr+is%3Aclosed

We probably should have made things a bit clearer about the current beta nature, so I have added a warning to the repo description.

Are edits to existing "tweet" files not noticed by the automation? So you had to keep making new filenames for them to be actioned? Like - it is a one-shot deal on these files?

Yes, that's correct. Twitter-together only detects newly added files via git, not renames / updates.

FYI we also need to be careful about renames and how git detects these so they are not accidentally re-tweeted.

Planning to document all this properly once we get our workflow sorted.

If so, we could at least deleted those two older versions out without any damage, to make it clearer. But not rename, because that would trigger a fresh retweet.

Yes, I was planning to clean these up next week when I spend more time on this, but as this repo was intended to be for testing I was keeping them around for reference until we nail down a process for dealing with these cases, which depends on what I can do in terms of improvements with twitter-together.

As for merging a copy of the tweets that @gitr0n1n made manually, I reckon this should either not be worried about for now, or be done elsewhere by some other format than files ending in tweet. As you noted, they will trigger a bunch of duplicate tweets once PR is merged, which will be confusing for people who have already commented/tweeted and lose their like count.

As @gitr0n1n mentioned, the intent was to get to a point where were a happy with our workflow and then fully switch to only tweeting from this repo, at which point the history would be maintained. Until then as far as @gitr0n1n making manual tweets, I agree it should be avoided, but during this testing phase due to errors / lack of engagement in this repo, seemed like a reasonable stop gap.

Changes to the examples to ETC_Network make sense.

[bobsummerwill]

OK - trimmed all those "retroactive" ones back out.
Was a useful learning exercise.