Approval for RescueTime connection

I’d like to ask for re-approval for the RescueTime connection that allows people to import their productivity data from RescueTime into Open Humans.

The project was previously approved but the status was then removed in the last purge. Going back to prior approval the project already has 11 users. As the unapproved status makes it impossible for other projects to request access to this data source I’d like to get approval again.

The project on Open Humans is here: https://www.openhumans.org/activity/rescuetime-connection/

The deployed project itself is here: https://ohrescuetimesource.herokuapp.com/

The source code is open on Github at https://github.com/gedankenstuecke/oh-rescuetime-source

my two concrete code suggestions from the Google Search project also apply to this project, and I have noted that DEBUG = False is already set here in the deployed version :slight_smile:

I vote to approve once those are implemented.

@beau Haha, I thought about checking that earlier this day and then totally forgot. But it’s now included (see commit here: https://github.com/gedankenstuecke/oh-rescuetime-source/commit/52d9d1916a5fcaa462d0192f0ab341aeef289141) and deployed with those updates!

Some notes on the content…

  • If this is going to be deployed as a personal project I think the language should avoid first person plural (no “our” and “us”). It could be “my” and “me” but in a lot of places I think it could be alternatively be switched to “this site” or “this app”.
  • I think I’d prefer the lead text to say who’s running it and overview of what Rescuetime data is & how to get it. e.g…
    “You can use this tool to copy your data from Foobar app into your Open Humans account. Foobar is a [free?] [open source?] thing that does X and collects data about Y and Z. This data transfer tool is a personal project of NameOfPerson, learn more on the about page.”
    … that hits the highlights of what I think really matters for “what it is” :slight_smile:
  • I’m sorry if I’m repeating myself but … I’m not comfortable with text and design that is shared with other projects, especially those officially operated by Open Humans. :slightly_frowning_face: I’d loved to see this deployed as an Open Humans project, if you’d like that. But if not… the overlap between something like this: https://ohrescuetimesource.herokuapp.com/about/ and this: https://oh-oura-connect.herokuapp.com/about/ is not good.

With respect to these persistent content overlap issues (which are due to forking open source site code) … I’m interested in creating a more standard set of text + style templates we can try to implement on all the officially-OH projects. I don’t want them used by other projects, to maintain a clear distinction. I’d rather not see projects copy each other too (unless it’s the same person, in which case… seems fine?)

I went through the copy again and replaced all we and us by me, I and this app. Unless my project-wide search missed some spaces. If that’s the case please let me know!

I reworked the lead text to that end…

I disagree on the overlap there:

For the visual overlap: The Oura (as well as Fitbit, Overland and all the other OH-run integrations) make use of the new CI and the OH-specific stylesheet to form a clear visual identity that belongs to OH.
For the textual overlap: As much as this is a consequence of being based on similar template, it’s also a consequence of the project guidelines which require projects to display these information on their project’s site to prospective users.

Does anyone else think that the layout leads to a risk of people mistaking this as an open humans foundation run project?

I still believe layout and wording do matter. To describe this as a design issue, it’s is a combination of two design heuristics: (1) consistent form, words, and actions, (2) provide a sense of place. The “sense of place” is whether one is using an official Open Humans project or not. To that end, people’s experience should be consistent across OH-run projects – in form, words and actions. (We have been bad at this.) And the “sense of place” shouldn’t be confused by those elements being re-used outside that context. (Which is what I took issue with here.)

But I think this project is OK to go ahead now, because we now have a plan to implement some new templates for the officially maintained apps (this repo is blocking on my input at the moment). We won’t allow substantial reuse of the new templates (layout, styles, or wording). But I don’t think it’s so important that the new template deployment should be blocking this project’s approval.

So… I vote for approve now. :slight_smile: (Any others want to weigh in?)

Closing this as approved. :+1:

(Please start a new thread to initiate a re-review process!)