Update contribution guidelines, based on suggestion by Enrico #280
Conversation
Co-authored-by: Enrico Glerean <[email protected]>
rkdarst
left a comment
rkdarst
left a comment
There was a problem hiding this comment.
I'd say it looks good. I added some suggestions.
I think it's important to also try to let people know what is wanted. There can easily be too many contributions, we want to help people know what is quickly acted on (= will be merged, feels good) and what might end up waiting a while for bigger design cycles (set expectations).
Co-authored-by: Richard Darst <[email protected]>
Co-authored-by: Richard Darst <[email protected]>
|
|
||
| ## The broad development process | ||
|
|
||
| Our lessons are continually in use as a reference (and sometimes taught by others), but it's OK if they continually evolve. A few times a year our self-hosted big courses happen: during these times, there is rapid development. Usually, we try to limit to incremental changes during routine times. Every so often, there is a period of big updates, where we'll look at all the accumulated bigger suggestions, the current state of the art, and what's needed, plan out a new lesson, and then implement it in time for the next course. A few lessons each year may get this treatment at most. |
There was a problem hiding this comment.
Not sure about all of this. It is how it is now, but these late night changes before the teaching are (hopefully) not what we want in the long run. The more we can do updates outside of the workshop times the better, in my opinion.
There was a problem hiding this comment.
I agree with "no late night edits", this is supposed to say it is sort of bursty before workshops though.
Thinking again I might say:
- Ideally some development all the time (incremental).
- This accelerates before our workshops (even if this isn't ideal)
- Big rearrangements happen periodically every few years.
There was a problem hiding this comment.
Admittedly, I think being honest here is a good thing. I don't think we will get rid of late night pushed around courses and while this is not optimal, I think I prefer it being this way, since it allows for more flexibility on the contributer side than doing more rigid runs.
What we could however try is doing some "in between sprints/hackathons where we dedicate time and go over material in a more focused way.
There was a problem hiding this comment.
What we could however try is doing some "in between sprints/hackathons where we dedicate time and go over material in a more focused way.
💯 Agree with that, but I also understand scheduling difficulties to regularly do this. We should try this at least once.
Additionally, it is also important to assign instructors way early. Doing so will give space to allow fixes to happen in a normal pace. This is important so that the instructors don't get burned out try to achieve the high bar they set for themselves / or by the community.
Whole team, please read with the eyes of someone not knowing anything about CodeRefinery.
Are those guidelines clear?
All necessary links provided?
Please comment or suggest in file directly. Let's make this useful guidelines that we can link to from all lessons!
My goal would be that someone coming out from their first CodeRefinery workshop could contribute, following these guidelines.
For that it needs some more work. Please help :)