Managing Project Week project descriptions

Community Project Week
1

In addition to the google sites and discourse-based options, we also tried the following:

  1. create a spreadsheet of all project using google sheets
  2. link the project details to a google slide within a continuous presentation

The order of experiments was:

  1. mediawiki (old style)
  2. combination of google sheets and google slides
  3. discovery of the new google sites
  4. google site (as mentioned by JC above)
  5. discourse (as mentioned by JC above)
  6. back to mediawiki
2

It’s been useful to explore these options - also good to know that the wiki wasn’t a terrible choice in the first place. It’s worked well enough that we can hold out for something that’s really good.

I do still think we should be encouraging Project Week attendees to start using the discourse forum for communication, as follow-ons to these discussions in the Winter:

https://na-mic.org/wiki/2017_Winter_Project_Week/UpdatingCommunityForums

https://na-mic.org/wiki/2017_Winter_Project_Week/Organizations

3

FWIW, the way to do this currently is to:

  • restrict “See” permission for the category to the ProjectWeek group
  • make all posts into Wiki posts
  • give every group member “minimum wiki edit” trust (TL1)
  • then everyone in the group could edit all posts.

When the Discourse platform updates to the next release (I don’t know ETA) then it will be possible to have Wiki posts visible outside the group, but only editable by members of group with “Create” permission on the category:

1 Like
4

We could have tried using github directly. You can create/edit files using only the web GUI and overall it’s not much more complicated than any other options.

There are several advantages compared to all alternatives:

  • full offline access! so you don’t have to worry about good internet connection during project presentations, even if you can attach high-resolution images or videos
  • storing project pages in a git repository for a project week is also a nice, compact, self-contained storage (easy to archive/migrate)
  • also possible to sphinx or other documentation generator to automatically convert to nicely formatted webpages or a single PDF
  • no need for yet another account (everybody has github account already)

Searching between multiple project weeks (if each project week is a separate repository) or indexing by search bots may be non-trivial, but maybe solvable by generating webpages. It may simplify things if all project week uses the same repository, as search within a single repository works quite nicely on github.

1 Like
5

Agreed. For reference, here is what I suggested few weeks ago:

That said, if we are going to change the format, I would suggest we:

  • allow direct link to each project summary
  • make it easy to process by a script
  • think about exporting existing entries to that new format
  • consider data mining

With that, we could then easily create an index all the projects across all years… and allow search by keyword, > participant, etc …
Having one Google slides per project week would make that hard.

Idea could be to have everything in one GitHub repo, use markdown, look at https://gitpitch.com/ ,

6

We can try this at the next project week, with/without gitpitch or similar tools.

1 Like
7

From @jcfr (2017-06-06):

We experimented with few approaches to improve and upgrade the presentation of projects worked on during the Slicer project week:

Despite our best effort, we resumed to use the traditional wiki Project Week 25 - NAMIC Wiki

  • Google site did NOT provide a way to revision the different versions. It is not made for collaborative editing.
  • Discourse provided supports revision but we did NOT have a clear pathway to manage edit rights on existing “pages” (or post)