📗 Open Ethnographer Manual

manual
project-open-ethnographer

#9

Out of the box with Discourse. There are actually two solutions:

1. Based on the project’s tag

Just go here: https://edgeryders.eu/tags/project-opencare?order=activity

Notice the ?order=activity at the end of the URL. You can click on fields to get your favourite reordering. “Activity” shows the topics in order of, well, activity: this includes creating the topic to begin with, but also adding new posts to existing topics (so far, so good). Unfortunately, you also get “uncodable activities”, essentially Likes and edits.

However:

This only makes sense after we have decided which posts are part of OpenCare. There is a semi-automated way to do this from the categories: I’ll write a separate mini-instructable in this category.

2. Based on tracking categories

  1. Navigate to the page of the category you want to monitor, for example https://edgeryders.eu/c/opencare/diy-and-open-source .
  2. Click on the last button on the right under your avatar, next to the “New Topic” button. It is normally marked by an empty circle.
  3. Select “Watching”.

At this point, when you log onto Edgeryders you will see all new posts in this category as part of your notifications. However, beware: this may mean a lot of email messages.


#10

Here is an instructable on assigning the project tag to entire categories and single posts:

https://edgeryders.eu/t/instructions-how-to-assemble-a-project-for-coding-in-open-ethnographer/7052


#11

@matthias We can have a call about this on your suitable timing :slight_smile:


#12

Thanks! Looks good.


#14

Hi @matthias and @alberto

I’m making a coding guide/course on OE, and I’ve realised that there doesn’t seem to be a way to merge codes in OE anymore, or to see the annotations associated with the codes.

Am I incorrect? If so, how would I do this?

My workaround for merging was to rename the code in question to the code I wanted to merge it to. But seeing the annotations associated with a code is important for forking codes (recoding already coded data under one code, say, ‘sustainability’, as ‘resilience’).

Thanks!


#15

For the report and papers I just used GraphRyder to see the text associated for the code, but for recoding it’s important to be able to do this in OE itself.


#16

You are right about this: issue #122 is about merging codes, issues #114 and #123 are about listing annotations.

How did you do this? If I try this, I get “Name has already been taken”. I seem to remember that we implemented this restriction later, so maybe you only used your workaround before we implemented that.

Right now, the closest you can get to merging codes is to group them below a common parent code in the hierarchy.

There is no workaround that I can think of. The most straight-forward way is to find some budget and ask @daniel to implement this (issues #114 and #123 as shown above).


#17

Seems likely that I implemented this workaround before that restriction.

The old OE had the capability to do these things (however clunkily :smiley: ) — it’s important that we are able to merge and fork, otherwise cleaning up codes is virtually impossible. So if it means finding budget to do so, I highly recommend we do it.

@alberto


#18

Agreed.


#19

Ok good :slight_smile: If (only if) @daniel wants to take this on, it should be around 600 EUR (12 h at 50 EUR/h). Paid by time, so this is only an estimate. If somebody else has to do it, it may be more, but 1000 EUR will be sufficient in all cases.

So once you found budget in that range, you can send me issue reports on Gitbub. :wink: Or more precisely, add a comment to the existing issue reports, mentioning that we can proceed with the implementation.


#20

The price is right.

https://github.com/edgeryders/discourse/issues/137


#21

Good, will be implemented as requested. You may add deadlines where they are needed, otherwise it’s on a best effort basis (and it’s not a big “project” anyway).


#22

I think @amelia has a timetable in mind. But yes, I can’t imagine it would be a big thing. A week.


#23

Nermine won’t need to merge or fork codes til a second pass, so we have a little time (a couple of weeks after she gets going). She also hasn’t replied to me yet so fingers crossed that happens soon! I checked in with her at the beginning of the month and she was still on board.


#24

And as if by magic she responded :slight_smile: we are good to start.


#25

@amelia and @alberto: The three features as discussed are ready to use since a few days, maybe you noticed already via Github or the OE software. In addition, I decided to let Daniel fix some of the more annoying issues in Open Ethnographer until the 600 EUR budget allocated above was used up. So in total, this is what we got for that budget:

  • #122 Allow Ethnographers to merge two codes. Allows normal users to merge their own codes only, and Discourse admin users to merge codes of different authors together. (That latter addition still has to be documented somewhere properly.)

  • #114 Implement annotation lists per code.

  • #123 Create a web interface to access annotations by author and by Discourse tag.

  • #89 Highlight own Open Ethnographer annotations when viewing a topic. @amelia specifically asked for this one some time back.

  • #108 Removing the non-working “Collections” UI elements.

  • Discourse admins can change code and annotation ownership. I’ll need that in the next days for example to assign proper ownership to the annotations Anu imported manually from the Drupal platform.

Invoice will follow shortly in FreeAgent, as usual.


#26

Great, Matt and thanks @daniel. I did see the GitHub notification but was not sure that the new code had been deployed. I’ll test it…


#27

For the discussion how the Discourse tags to mark Open Ethnographer projects should look like:

The project-* tags were supposed to keep together content of our various client projects even after they finish and we sort in their content elsewhere. See the “Admin tasks for edgeryders.eu” manual at “Tags for project content”. The idea is that we will eventually have a nice list, for example on the “Company → Our Work” page, with links to the complete content of each project we did.

For that reason, all OpenCare content (including the one not meant for Open Ethnographer) should have the #project-opencare tag. And all content should only have one project-* tag because it only belongs to one client project we do. So in this scheme it’s not possible to introduce project-opencare-oe-selection either.

Proposal: I was thinking of introducing project-specific tag namespaces that can be used however people like (and give the assurance that mods and admins won’t mess with them). They would start with the project name as prefix, and anything afterwards. So @amelia could use opencare-extracontent or similar to mark OpenCare content outside the OpenCare category that should be coded in Open Ethnographer. By including this in a tag group with project-opencare as parent tag, it is also ensured that nobody can use this tag outside of OpenCare content.

If you agree, could you update your instructions above accordingly?


#28

Your naming convention proposal is a bit unclear. It assumes that every ethnographic research project has to have a correspondent client project, but that’s not necessarily the case. For example, you could have a project called “Alberto’s thesis”, launched by a student called Alberto that approached us with a good idea and obtained access to the data.

So, I’d rather have a prefix for ethno projects, for example ethno-PROJECTNAME.


#29

Makes complete sense. Please go ahead with that :slight_smile: