JupiterBroadcasting / jupiterbroadcasting.com

JupiterBroadcasting.com, hugo-based and community-driven!
https://jupiterbroadcasting.com
99 stars 49 forks source link

Geocatching details on site #465

Open takov751 opened 1 year ago

takov751 commented 1 year ago

Feature Description

@gerbrent my idea is to use as you thought GitHub just in somewhat different way . My idea is to create issue here or on an empty repo called geocaching . So all the activity in issue would be separated . Then create issues on that repo for every geocaching location in a template manner. So that JB listenesers could add their own as well. And moderator specifically to these issues could a label for example geocaching-active and then when Hugo websites builds it would crawl trough this repo issues and create a list from the active label. Then parse each issue for comments and generate website for each containing the details from the issue opener post and add comments from the issue comment.

This would take far longer . Or just use that repo to generate that subfolder for the website and everytime website built the pipeline would fetch repo

Reference to Feature

No response

takov751 commented 1 year ago

And So comments for each geocaching could be similar to https://github.com/utterance/utterances

CGBassPlayer commented 1 year ago

So I think using issue to keep tracking of geocaches would be need to be a repo separate from the website itself.

My idea of this would be that open issues could be the geocaches are that out in the wild and they would close once they are found. I am not sure that using GitHub issues is the best way to handle something like this, but I am definitely open to using it.

Looking for others thoughts about this

takov751 commented 1 year ago

And if the geocache treasure box refilled with stuff open issue once more

gerbrent commented 1 year ago

This is a pretty good implementation of my hardly-at-all-pondered idea! I like it...

The only other alternative I can think of is to use a PR and submission method, but perhaps carries complexity for no reason.

gerbrent commented 1 year ago

OK, here we go for the alternative:

We could track the geocaches with hugo-esque files, mostly w the metadata:

{
  "type": "geocache",
  "draft": false,
  "show_slug": "coder-radio",
  "cache_name": "Washington Pass Overlook",
  "description": "Washington Pass Overlook - North Cascades Highway\n",
  "cache_hint":"Look off the beaten path, within nature's steps."
  "date": "2022-10-24T11:36:33-07:00",
  "header_image": "/images/shows/photo-from-Washington-Pass.png",
  "categories": [
    "Washington"
  ],
  "tags": [],
  "geocachers": [
    "brent",
    "nextCacheFinder"
  ],
  "photo_gallery": "link to photo gallery"
  "audio_file": "link-to-audio-description-teaser.mp3",
  "video_file": "link-to-video.mp4",

}

advantages to this approach

disadvantages

photos, audio, video:

other details to capture could include:

CGBassPlayer commented 1 year ago

Love the idea of doing it the Hugo way the idea to build on @gerbrent’s idea of the template objects. But I did have some concerns.

Video and Audio

Git does not handle binary files like videos and audio recordings well and could balloon the repo to a very large size, I would say even with Git LFS (which would a another setup step if we decided implement it I believe. I haven’t used it before, so I cannot confirm). I would vote towards a separate place to upload them (link to a YouTube video or something similar) to keep the repo lean.

Activity

To maintain the geocaches activity, are you thinking about having the geocache metadata be updated? Or were you thinking of more of a timeline style?

If we are updating the geocache object itself, we would have to get automation to get updated information to develop and directly to main so the community can stay up to date with the caches.

if we do a timeline style, we could add an array of objects to the metadata


{
  "type": "geocache",
  "draft": false,
  "show_slug": "coder-radio",
  "cache_name": "Washington Pass Overlook",
  "description": "Washington Pass Overlook - North Cascades Highway\n",
  "cache_hint":"Look off the beaten path, within nature's steps."
  "date": "2022-10-24T11:36:33-07:00",
  "header_image": "/images/shows/photo-from-Washington-Pass.png",
  "categories": [
    "Washington"
  ],
  "tags": [],
  "geocachers": [
    "brent",
    "nextCacheFinder"
  ],
  "photo_gallery": "link to photo gallery",
  “events”: [
    {
      “datetime”: “2022-10-27T09:34:00”
      “description”: “”
      “user”: “”
    }
  ]
}

Barrier to Entry

Like @gerbrent had said, the barrier to entry to update these caches is very high for a non developer. Which makes me worry that we implement an entire new section of the website (and the automation behind it) just for it be left unused. —-

Love the idea. But we need some serious thought out into this before any code gets written

gerbrent commented 1 year ago

I love how reasonable you always are @CGBassPlayer - so appreciated!

And yep... judging by the amount of activity on the caches so far (one found, another almost found but no luck, another visited but not searched for..) I'm also not convinced this idea of geocaching has long legs.

Wouldn't want to build something (surely amazing, if all of everyone's collaborative contributions so far are any indication) that never gets used.....

gerbrent commented 1 year ago

timeline/array of objects sounds like what I was picturing!

takov751 commented 1 year ago

I was really thinking to create a permanent drop-off geocatch in mid-west, North Wales in UK. with some swag. However I have to say this will be rarely active. Nevertheless, that only means easier to maintain

I love how reasonable you always are @CGBassPlayer - so appreciated!

And yep... judging by the amount of activity on the caches so far (one found, another almost found but no luck, another visited but not searched for..) I'm also not convinced this idea of geocaching has long legs.

Wouldn't want to build something (surely amazing, if all of everyone's collaborative contributions so far are any indication) that never gets used.....

You could it's rarely used, but I would say that means it's easier to maintain in the long run, at still deliver useful feature in case there would be a more permanent geocatch treasure drop point for swags.

CGBassPlayer commented 1 year ago

@gerbrent Is there a particular Matrix room that would be a good place to poll the community about the idea of geocaching? I know feedback in the shows has been pretty sparse so I’m wondering Matrix would be a better place to find out.

@takov751

However I have to say this will be rarely active. Nevertheless, that only means easier to maintain

You could it's rarely used, but I would say that means it's easier to maintain in the long run

I actually disagree with you there. It’s not so much that it’s easier to maintain, it’s more the issues related to it trickle in slower, meaning bugs would end up undiscovered longer than if it had more eyes on it. I actually ran into this issue with something at my job. A process was barely used for years and when it was finally getting implemented by customers, tons of bugs were found.

The other thing that would have to be considered is the initial creation time. An addition like this doesn’t seem too hard on paper, but would end up taking a decent amount of development time.

I was really thinking to create a permanent drop-off geocatch in mid-west, North Wales in UK. with some swag.

I think that is awesome! Definitely go for it! You could probably even let people know in the London meetup Matrix Room as well.

takov751 commented 1 year ago

@gerbrent Is there a particular Matrix room that would be a good place to poll the community about the idea of geocaching? I know feedback in the shows has been pretty sparse so I’m wondering Matrix would be a better place to find out.

@takov751

However I have to say this will be rarely active. Nevertheless, that only means easier to maintain

You could it's rarely used, but I would say that means it's easier to maintain in the long run

I actually disagree with you there. It’s not so much that it’s easier to maintain, it’s more the issues related to it trickle in slower, meaning bugs would end up undiscovered longer than if it had more eyes on it. I actually ran into this issue with something at my job. A process was barely used for years and when it was finally getting implemented by customers, tons of bugs were found.

The other thing that would have to be considered is the initial creation time. An addition like this doesn’t seem too hard on paper, but would end up taking a decent amount of development time.

I was really thinking to create a permanent drop-off geocatch in mid-west, North Wales in UK. with some swag.

I think that is awesome! Definitely go for it! You could probably even let people know in the London meetup Matrix Room as well.

You are absolutely right about that. I was not thinking that ahead.

gerbrent commented 1 year ago

First, @takov751 definitely place the geocache and let us know about it! Would be very happy to include the drop in LUP.

gerbrent commented 1 year ago

For a matrix poll, I'd say actually the main JB Chat would be the place - reach the most people for an accurate general poll.

I can take care of that..

TeamLinux01 commented 1 year ago

I had the idea that each geocache could have a unique token ID and a QR code could be printed that is a URL with that token filled in.

If a web page could be built that shows which geocaches are out there and not been found, then if someone scans the QR, they could easily claim that geocache.

gerbrent commented 1 year ago

now that is a fabulous idea @TeamLinux01 . hmm!

elreydetoda commented 1 year ago

This has been some awesome discussion, I've actually created a GH discussion to try and consolidate all these great ideas (and hopefully others) into one location. GH discussions also has a "voting" feature by allowing you to up-vote individual suggestions, so that should help with the "polling" side of things.

So, @takov751 or anyone else on this issue would you mind submitting the consolidated information from this issue to the discussion: https://github.com/JupiterBroadcasting/network/discussions/13