web-service

[arve0]

It would be simpler for new contributors if the builder had an interface which hides some of github's features.

@kwrl You did start on this, do you have any code that is relevant?

[kwrl]

I don't really have any relevant code. I basically just combined the ace web editor with a simple php backend for converting markdown to html.

What features would you like to include in this interface?

[kwrl]

Creating a fork through Github's API seems rather straight forward.
https://developer.github.com/v3/repos/forks/#create-a-fork

This could simplify the initial setup somewhat.

[arve0]

I do no longer agree with myself, I'm not sure this is a great idea. It's best explained with an analogy:

Suppose you have the option to give your child a sharp whittle knife or a blunt butter knife. The sharp one will impose danger, but the knife is highly useful. A butter knife on the other hand is not that useful, but it's safe. I will suggest that going for the safe choice is doing your child a disservice, as the child will quickly learn the sharp knife's nature and be better off with the extra skill.

[gahjelle]

Hmm ... I am thinking that for most people (e.g. teachers, volunteers) that we would love to have contributing projects, they would simply choose option number three - no knife, and we would end up doing all the work for them ... I still think it is useful if they can butter their own bread ... :)

[arve0]

🍞 + 🍴 = 🎉 ?

[gahjelle]

Bread and circuses ...

[gahjelle]

To be possibly a little clearer on my thinking:

One of our main goals is to have more people contribute projects, maybe especially teachers and volunteers with some experience in teaching kids (either coding or other things). Most of these people will not have git (or other similar tools) experience, and will not see knowing git as a useful skill to have (outside of contributing projects to us) (Whether git actually is a useful life skill is a different question ...).

Thus, the more "magic" buttons people have to click or "weird" words people need to learn before being able to contribute, the less people will help us out.

I would love for more people to the discover the joys of git, but I am afraid forcing them through github-hoops here will not help.

[arve0]

I'm again convinced this is a great idea! Maybe the code for this should live in another repo?

[kwrl]

I agree with @gahjelle on this one. Our goal should be to simplify the process of contributing projects, not forcing git down teachers' throats. We can start Lær Kidsa Git in a couple of years (everybody knows how to code by then, right?).

However, implementing this interface will not be straightforward. How do we handle possible merge conflicts etc? If the users have to use the CLI every time something unexpected happens I don't think we will have accomplished much.

[arve0]

As a first move and proof of concept:

• the interface will always show the master of the lesson repo
• any change will always open a new PR

This way, one is limited a lot, but the coding should be straight forward.

[arve0]

Adding: Fixing conflicts will be the administrators job.

[gahjelle]

I think the simplicity of @arve0's suggestion might be very powerful.

It will be very easy for the contributors. We - admins - can handle the technical stuff, including conflicts. I do not think there will be many conflicts.
We then only need to manage expectations in terms of it taking some time before people's changes show up on the official page, but that should be doable!

[arve0]

https://github.com/michael/github

[arve0]

Begun here: https://github.com/arve0/lesson_editor
Demo: http://arve0.github.io/lesson_editor/