Specified what self-organised workshop is #864
Conversation
|
👍 |
| <ul> | ||
| <li>covers our <a href="#core-topics">core topics</a>, </li> | ||
| <li>has at least one <a href="{{page.root}}/pages/team.html">certified instructor</a> teaching,</li> | ||
| <li>runs our standardised pre- and post-workshop questionnaires and provides us with the results,</li> |
There was a problem hiding this comment.
Can we add a link to these questionnaires?
There was a problem hiding this comment.
IIRC, I think the generating of these are An Issue (TM) (aka Arliss does it) which they aim to solve with AMY?
There was a problem hiding this comment.
Indeed, currently we don't have a mechanism to allow the hosts manage (create, instructors to preview the annonymised answers to prepare for the workshop etc) the questionnaires themselves (even if they want to). So link is not available. For the moment, admins do it but yes, I'll double check AMY and hopefully I can help to sort this out.
There was a problem hiding this comment.
So, you're saying it is acutally impossible to have a self-organized workshop because it's impossible to "run our standardized questionsairres and provide the results" ?
This is a serious circular issue.
There was a problem hiding this comment.
On Mon, Mar 09, 2015 at 11:47:02AM -0700, Katy Huff wrote:
So, you're saying it is acutally impossible to have a self-organized
workshop because it's impossible to "run our standardized
questionsairres and provide the results" ? This is a serious
circular issue.
Until it is possible, I'd suggest dropping (or just not merging?) the
questionnaire requirement.
There was a problem hiding this comment.
Or maybe (for now) say "run, provided by us, standardised questionnaires"? @wking - dropping this requirement completely is not ideal as we need to collect the data, so we should say upfront, that the questionnaires will have to be distributed.
To @katyhuff - yes, at the moment an external person (host) is unable to access the questionnaire template to create an instance of a questionnaire for their workshop.
There was a problem hiding this comment.
On Tue, Mar 17, 2015 at 05:57:28AM -0700, Aleksandra Pawlik wrote:
Or maybe (for now) say "run, provided by us, standardised
questionnaires"? @wking - dropping this requirement completely is
not ideal as we need to collect the data, so we should say upfront,
that the questionnaires will have to be distributed.
If there's a way that folks can handle the questionnaires while still
remaining a self-organized workshop, that's all I was concerned about.
I don't mind if it's steps for the host to follow to distribute,
collect, and submit the questionnaire, or if we're having admins
donate free time to facilitate some of that, so long as there is some
path open for self-organized workshops.
|
+1 to this, I think it looks good. |
| <a href="#core-topics">core topics</a> | ||
| has at least one <a href="{{page.root}}/pages/team.html">certified instructor</a> teaching, | ||
| and sends us summary information about attendees. | ||
| We normally grant this to any training course that: |
There was a problem hiding this comment.
Add
- has a home page following https://github.com/swcarpentry/workshop-template (this don't need to be the main home page for the workshop).
There was a problem hiding this comment.
On a technical note, don't the workshops (at least the url) have to follow our format to be displayed correctly on the website?
There was a problem hiding this comment.
@karinlag They have to be compliant with some specifications. Obviously, it's unlikely someone will create their own version of the template), however I think that @r-gaia-cs suggestion is a good idea - we should make it explicit to the self-organised workshops what we want from them.
There was a problem hiding this comment.
On Tue, Mar 17, 2015 at 07:12:21AM -0700, Aleksandra Pawlik wrote:
They have to be compliant with some specifications. Obviously, it's
unlikely someone will create their own version of the template…
Making this explicit would help, but do we need to have a homepage
before something can be a SWC-branded event? In amy, the Event.url
field is blank and nullable 1, and it's been nullable since the
field landed in carpentries/amy@e75538a5 (Displaying repositories for
workshops, 2014-12-01) as Event.repo. Personally, I like it when
events have a public homepage, but I don't think we should require it
before allowing them to use SWC branding.
There was a problem hiding this comment.
do we need to have a homepage before something can be a SWC-branded event?
No. What we need is that the workshop has one homepage that we can get the metadata.
@gvwilson and @wking Can we replace https://github.com/swcarpentry/site/blob/master/bin/preprocess.py and https://github.com/swcarpentry/site/blob/master/config/workshops.yml with queries to amy? If this is the case, I'm +1 to leave the host has the workshop homepage as s/he prefer.
There was a problem hiding this comment.
On Tue, Mar 17, 2015 at 10:20:25AM -0700, Raniere Silva wrote:
Can we replace
https://github.com/swcarpentry/site/blob/master/bin/preprocess.py
and
https://github.com/swcarpentry/site/blob/master/config/workshops.yml
with queries toamy?
Sure. It looks like the logic we want to replace is actually in
https://github.com/swcarpentry/site/blob/master/bin/workshops.py. I'm
happy working up a pull request that hits amy for this data, asking
for a valid username/password to authorize the amy request.
There was a problem hiding this comment.
- +1 on querying Amy for URLs of upcoming workshops.
- We should fetch the actual info of those workshops from their
websites (since instructors, rooms, etc. can change at the last minute). - We need to archive info about past workshops in the
siterepo -
can't be sure their repos will still be there in a year.
There was a problem hiding this comment.
On Wed, Mar 18, 2015 at 06:08:11PM -0700, Greg Wilson wrote:
- +1 on querying Amy for URLs of upcoming workshops.
I was suggesting querying amy for all the data, and not requiring a
workshop URL.
- We should fetch the actual info of those workshops from their
websites (since instructors, rooms, etc. can change at the last
minute).
I'm ok with this if the workshop has a URL, but I'd rather have
workshop URLs continue to be optional. I'm not sure how this works
currently (I'd expect you'd need to rebuild swcarpentry/site to get
the new values anyway?). My favorite approach here would be to have
the swcarpentry/site listing hitting a public, CORS-enabled amy
endpoint to get this data dynamically, and then have amy periodically
poll pending workshops with URLs to pull in new data from the workshop
pages. Once we give instructors access to amy to update their pending
event data directly, we can drop the polling.
- We need to archive info about past workshops in the
siterepo- can't be sure their repos will still be there in a year.
I'm suggesting we store all of this in amy, so that shouldn't be a
problem.
| @@ -238,11 +238,20 @@ | |||
| for details. | |||
| </li> | |||
| <li> | |||
| Groups that are doing setup and administration for workshops themselves | |||
| are not expected to pay this fee | |||
| Self-organised workshps are not expected to pay this fee | |||
|
@apawlik @karinlag @jiffyclub ping... |
|
For my part, I think it's good to go. @apawlik , what do you think? |
|
Sorry about the delay. I think at the moment this could (?) be merged. |
|
@apawlik - I actually don't think it's ready just yet - There are a handful of (mostly minor) comments that haven't yet been dealt with, also there appear to be conflicts with the base branch. |
Otherwise, some times are read as strings instead of ints, because YAML gets confused about fields with colons that start with 0's, as in '09:00:00' (no, really).
Otherwise, some times are read as strings instead of ints, because YAML gets confused about fields with colons that start with 0's, as in '09:00:00' (no, really).
Convert maps to lists so PyYAML works.
Python3 doesn't have unicode function.
|
What's the status of this one? |
python3 ./bin/preprocess.py -c ./config -o /home/raniere/software-carpentry/site/_site -s /home/raniere/software-carpentry/site/_site
Traceback (most recent call last):
File "./bin/preprocess.py", line 253, in <module>
main()
File "./bin/preprocess.py", line 114, in main
decorated.sort()
TypeError: unorderable types: dict() < dict()
Makefile:213: recipe for target '_config.yml' failed
Simply add retrieval of badges.yml, airports.yml before they're used in generating `_config.yml` by `preprocess.py`.
List of airports is now closer to the list of badges (ie. people are
2-field objects:
{name: 'Piotr Banaszkiewicz', user: 'banaszkiewicz.piotr'})
And the list of instructors is called `instructors`, not `who`.
List of badges is not a dictionary anymore, so additional lookup is required (via loop and if). Also, people are in a field called `persons`, not in the unnamed list.
This is quite a big commit, but the basic changes are here: 1. No archive for workshops (since they're accessible via AMY API) - that'll change soon, ie. we'll add a 'make archive' option 2. Fixed duplicate command in Makefile 3. All workshops are marked either published or unpublished by `preprocess.py` because AMY returns all workshops considered published by its own criteria (less strict). 4. config/airports.yml, config/badges.yml and config/workshops.yml aren't needed anymore, since that data comes from AMY 5. Some fields changed names (ie. `startdate` became `start`, `enddate` became `end`). That was quite straightforward to fix.
|
@apawlik ... do you want this to be merged? there appear to be conflicts... |
|
Closing. There is a new, updated PR coming. |
Changes based on the Steering Committee discussions.
The main change is conditions that need to be met by a workshop to be considered self-organised (this needs to be specific; these workshops are not requested to pay the fee).
And a small update to the conditions for using the brand - the hosts need to run the questionnaires and provide us with the results.