Teletype codex: community github script repository


#21

Yes contributors have direct push capabilities. They can also merge PRs. (edit: I think they’re actually called collaborators.)

My suggestion would be the only people that really need contributor status are the curators of the codex, and that all contributions should generally go via a PR. This gives the curators the opportunity to ask for format changes or via the magic of git cherry-pick (or interactive rebase) make the changes on behalf of someone else while maintaining authorship (e.g. this commit to Teletype). It also makes it easier/safer for new users to git, as you can easily get in a muddle with direct repo access.

GitHub tracks code contributors and code ownership independently of who has contributor status on the repo, e.g. see the listing for the Teletype repo (go me!). That’s the best way to show people recognition.

Also, if you’re willing to put the time in, it’s better to go with the benevolent dictator for life model. Or at least a core group of dictators. Time and effort are the limited resources, not opinions. I’ve seen open projects sidetracked due to too many opinions. So if you have a plan go for it, you have my vote for BDFL.

One last thing, hopefully Hacktoberfest will happen again this year. In short anyone that opens up 4 PRs on GitHub in October gets a free T-shirt from GitHub (where we store our code) and Digital Ocean (where lines is hosted). It might be a fun way to drum up interest in contributions to the various Monome open projects (this, the Teletype docs, etc).


#22

Thanks!

I’m happy to take on primary maintenance and curation. I’ve already added a few of the regular contributors to this thread as collaborators, so that should be a good core group to get us going.

For anyone else that has stuff they want to contribute, please go ahead and fork/clone at your pleasure, and when you have something you want to share we can do a PR and get it in the main repo.

Looking forward to seeing how this goes!


#23

invites out–

warms my heart that y’all have github accounts


#24

i’m so happy this is happening. please add me as well: shellfritsch


#25

I don’t have a Teletype yet but I’d probably be interested in reading things/scripts there…
I’m oscillateur on Github too.


#26

Splendid! I think a central curator(s) amanaging pull requests, rather than individuals pushing their own changes, is a better way of managing things. I’m gonecaving on GitHub.


#27

please add me too: madeinspace


#28

before joining this forum, I had no idea what github was or that I could possibly understand how folks edit a max patch to make music, lol…


#29

sweet! Please add me as well. user: courdek


#30

how did i miss this thread all week?

please add zunaito


#31

edit: forget about it, no need to add me.


#32

I think the repo is public, so you should all be able to view, clone, and fork it. Once you do that you can add your scripts and we can merge them back in.

I don’t think we need to explicitly add everyone to the Monome group, or do we @tehn? I’m not that familiar with how groups work.


#33

me neither

just throwing my name in there in case it’s necessary


#34

Great, I threw in the first pull request.

I have two commits on my fork:
-All factory docs and default scenes. TT Studies is preset as a PDF, but not yet available as .txt files.
-All files found through searching for “.txt” here. There are many more TT scenes available here, but I thought I would start with the ones that were already formatted.


#35

Thanks for doing that! It is now merged and ready for anyone who wants it.


#36

i’ve been thinking that the codex could be used not just for scenes/scripts but also some related documentation which can be as simple as a short description or a breakdown of a scene or a complete study or anything in between. and such documentation can be a work in progress, i think it would encourage people to add more scripts and document them as their time allows.

how should we document? a corresponding readme file for each scene? or should we use the github wiki? with wiki you have the benefit of using markdown, and it would be easier to link things. it would also be nice to have a central starting point which would list all of documented scenes, categorized. this could become an extension to the official studies and perhaps we could link to it from there.


#37

The wiki is great for more general info and documentation. For scene specific docs I would tend to use a readme in the scene dir. GitHub supports markdown for readme, just call it readme.md and it will be displayed under the file listing.

I’m up for experimenting with it until we hit on something and fills the need.


#38

As a relatively new Teletype adopter, I would definitely like to encourage a wider sharing of scenes. If this helps (and it seems like it would), then I’m all in.


NOTE teletype op
#39

While I think your proposal has a lot of merit in its own right, I think the main issue with a lack of sharing is a human problem. I suspect that the barrier is threefold (at least)

  • Technical know-how required to commit to git. I think this is easily solved, but having a few people who could commit on behalf of those who can write TT scripts, but don’t want to learn how to use git. I’m happy to help in that regard.
  • Fear of looking like a novice. I think this is likely less of a concern in this forum than elsewhere, but probably still some part of the issue.
  • Personal high standards. along the lines of “this isn’t good enough to share”, or “my script isn’t finished yet, I’ll share it later” (and it’s never “finished”). As can be seen in the various TT threads, there’s huge value in sharing even small snippets of code. Could this be addressed by adding a part of the repo for snippets?

#40

I think this is a wonderful idea.
reusability is indeed a concern (no fun to port a scene to address a different module after squeezing logic into the available script space). this alone makes it worthwhile imo.

full support!

re:

valid point. would be nice to have a non-coder friendlier layer on top of it. gihub itself does that… but

no easy solution without losing repo control I guess.
but I digress.