GitHub collaboration scheme

philwareham · 2017-03-12 15:30:17

Destry, you might want to look at Prose for editing GitHub Pages (Jekyll). I decided against using it for Textpattern Docs as generally contributors were git savvy. Might be valuable to you though.

Destry · 2017-03-12 16:35:38

Thanks Phil. Joshua Vauge mentioned that to me as well. Also Forestry, though I won’t be paying for open project.

michaelkpate · 2017-03-13 01:33:22

Destry wrote #304631:

We even tried using G Docs for the drafting phase of this project (realizing we’d have to manually port all the drafts to the publishing system later), but it was just too cumbersome for the communication side of the collaboration. The little margin comments in a doc was out of control and too hard to manage when you have more than a handful of people working together. Plus there was no real good way to track the status of a given draft. Further still, G Docs are a poor choice when the collaborative writing is on many pages of web content (unless production location is wordpress.com and group is using something like Wordable).

I really wish Google hadn’t given up on Google Wave so quickly.

maverick · 2017-03-13 02:04:55

michaelkpate wrote #304646:

I really wish Google hadn’t given up on Google Wave so quickly.

Google’s knack for starting things, letting them languish, then exiting has led me to be quite cautious about overly embracing their products. gMail and their basic productivity suite seem to be long term commitments, but Wave, Reader, Motorola, Pixelbooks, Hangouts, Google+, and so many other things seem to come and go from them.

bici · 2017-03-13 06:00:55

i was a very early adopter gMail having received an invitation ( in those days you got an account by invitation only). It was a good application, and spam killer extraordinaire but for the past 4 years or so it’s UI like so much of google’s other apps … stinks the big one.

edit: let me end on a happier note Happy Holi

Last edited by bici (2017-03-13 06:03:23)

Destry · 2017-03-13 09:02:12

I still have my Gmail account for when I need to use Drive, but all of my email use now, except for a couple of domain name accounts, is with Protonmail. Proton was originally developed by CERN’s IT folks and has spun into its own email service business, with big emphasis on email security. The servers are in Switzerland too, so out of Trumps legal demand.

I might as well mention Wire too, which is a great chat service (text, video, groups…) along the lines of Signal in terms of security. But again, Wire’s servers are in Switzerland, not Silicon Valley. Not an American company. Unlike Signal it provides both mobile and desktop clients.

Oh, and continuing in the security vein for those on Apple gear, Better is awesome.

Anyway, something more topic-focused…

I’m going to see if these instructions to sync a GitHub fork can be done using the GitHub client too (instead of command-line). If not, then I may have to make a project decision to give all collaborators “push” rights to the master, because nobody will bother with the technical hurdles otherwise, unless they are already skilled GH users, which won’t be the case for most people. Contributing via a clone and via a desktop client, however, is something they should be able to manage, and would get their foot in the door with GitHub.

bici · 2017-03-13 16:57:02

thanks Destry., purchased Better. now i feel better! I should use ProtonMail more often…

Destry · 2017-03-23 07:55:39

Phil,

I’m a little confused about how styles work in GitHub Pages. I’m using Jekyll in relation to GH-P. I didn’t install Jekyll locally or separately. I’m just trying to do everything through the repo. I’m figuring it out, mostly — using includes and variables and such — but I’ve set up this directory, /assets/..., where I have images and css file, but the directory is just ignored no matter what I try. What’s the trick?

I’m not using a theme and overwriting the theme CSS. Jekyll seems to use Sass or Less or something, which I hate. Most of the documentation I find is discussed in that respect, thus not very helpful. I’m just creating a presentation from scratch, or at least that’s what I want to do.

It looks like you have the Txp docs CSS file as an external link (outside the repo project). I’d prefer to keep it in the repo, which makes updating it a lot easier, in context with other repo files and without having to use SFTP to another web host.

Last edited by Destry (2017-03-23 10:08:39)

philwareham · 2017-03-23 10:55:23

Hi Destry,

The reason the docs site uses an external URL for the CSS/JS is that the same assets are shared by the docs site and the (future) textpattern.io main site, to make dev efforts easier. The assets are stored on textpattern.io not the docs.* subdomain.

For a GitHub Pages site you can just write some vanilla CSS into a file and commit that to your repo anywhere you like, then link it in the head of your pages, just like any standard HTML site. Maybe your Jekyll site template has a .gitignore file that makes it ignore the assets directory and any files within it?

Or… you can create Sass files and the system will auto compile those automatically – although I don’t use that feature (I’d prefer to have more control over my Sass build chain).

Destry · 2017-03-23 11:39:50

philwareham wrote #304998:

The reason the docs site uses an external URL for the CSS/JS is that the same assets are shared by the docs site and the (future) textpattern.io main site, to make dev efforts easier. The assets are stored on textpattern.io not the docs.* subdomain.

Makes sense.

For a GitHub Pages site you can just write some vanilla CSS into a file and commit that to your repo anywhere you like, then link it in the head of your pages, just like any standard HTML site.

This is what logic would suggest, and what I’ve been flailing with. But your confirmation on the matter made me take a harder look…

I realized an image was showing up, so it wasn’t the entire /assets directory, just the css file. Then when comparing the working file path with the css file path, I spotted the issue. Normally a repo URL has pattern, github.io/org/repo, but when a GH Page is used, the url is changed to org.github.io/repo. Was using the old path.

I’m using an include for the domain now, so when I change to a custom domain, I can change them all with one file.

Sorry for the trouble, but it helped me double down on where to look and thus find the problem.

Textpattern CMS

Textpattern CMS support forum

#13 2017-03-12 15:30:17

Re: GitHub collaboration scheme

#14 2017-03-12 16:35:38

Re: GitHub collaboration scheme

#15 2017-03-13 01:33:22

Re: GitHub collaboration scheme

Destry wrote #304631:

#16 2017-03-13 02:04:55

Re: GitHub collaboration scheme

michaelkpate wrote #304646:

#17 2017-03-13 06:00:55

Re: GitHub collaboration scheme

#18 2017-03-13 09:02:12

Re: GitHub collaboration scheme

#19 2017-03-13 16:57:02

Re: GitHub collaboration scheme

#20 2017-03-23 07:55:39

Re: GitHub collaboration scheme

#21 2017-03-23 10:55:23

Re: GitHub collaboration scheme

#22 2017-03-23 11:39:50

Re: GitHub collaboration scheme

philwareham wrote #304998:

Board footer