Indexing job opportunities.

[berkes]

One use-case for Flockingbird is to help people in their job-hunt. And to help organizations in need of talent to find it in the fediverse.

In the end, this should be covered when you sign up on a Flockingbird instance. But until we have that, we can release an intermediate product that does just this:

• index job offers "tooted" into the fediverse in a search engine on one side: "search for Job openings"
• crawl and index profiles of people who have a tag (e.g. #forhire) on their profile: "search for Candidates".

This idea is taking form, and some technical outlines are drawn.

But lets first discuss this idea a bit further. Some questions that arise are "do we actually want this" or "is it OK to index public profiles in a search engine". And many more questions that you probably have.

So, let's go: What do you thing? Do we need this? Do we want this? How would you build this?

[berkes]

Since I've started researching this further, here's some resources:

It started with a poll on the fediverse.

There is a design on penpot, which is really just one proposal, certainly not a requirement.

We'll be capturing the details in #37 . Which already has some details; but all those are open for discussion.

And out of that come some tasks. For the impatient, or those who prefer to code instead of discuss, there are #38 and #39 , #40, #41 and potentially more in future under the fedifind tag in the issues.

[stevefloyd]

My main question would be...

1. what is the technical debt and added resources required for administrators (and if so, what does that look like in production)?
2. Is this going to violate privacy laws in any jurisdictions?
3. could this feature be offloaded client side, removing concerns from Feature/ci #1

I built a toxic link audit tool back in the early 2010s that I sold and we used Scrapy extensively. There are just so many things that can go wrong, this could end up being a blackhole for dev resources to maintain and get stable (at least from my experience).

If a website changes how their front end displays data, it's like playing whack-a-mole. Leveraging APIs are cost prohibitive as well, so scraping is probably the only viable route to achieve this.

[berkes]

Good questions!

• what is the technical debt and added resources required for administrators (and if so, what does that look like in production)?

I'd prefer this to be completely separate from Flockingbird main repos. So a standalone Open Source project.

• Is this going to violate privacy laws in any jurisdictions?

IANAL, but the common denominator would be the GDPR. Which means it needs to have a clear way to have content removed.

For the rest, it should index only context that is publicly accessible. I can hardly imagine this to violate privacy laws.

• could this feature be offloaded client side, removing concerns from Feature/ci #1

Interesting idea. I can't envision this, now, could you maybe explain how this would work?

[stevefloyd]

IANAL, but the common denominator would be the GDPR. Which means it needs to have a clear way to have content removed.

In a federated network that kind of guarantee simply isn't possible but all data should fall within the public domain anyways, so probably not a major concern.

Interesting idea. I can't envision this, now, could you maybe explain how this would work?

Well, like all those SEO browser extensions that effectively use their users to scrape bits of data, offloading those requests coming from a proxy or their own centralized server (making it much harder for admins to block as well).

Maybe a "FlockingBird Job Search Extension" or something that feeds results into their profile / account ID.

That adds additional complexity and moving parts for you (and the users) though, so may not be the best route.

[berkes]

Every Penpot link you've posted (including the one in the README) is broken when I try to visit it.

Weird. I double-checked, using private mode in firefox. It works there. Penpot is a complex web-app, so it could be a plugin or other blocking mechanism that is causing it to break.

Right. I moved around some work. This one works in Chrome and Brave: https://design.penpot.app/#/view/f0afd050-8431-11eb-9126-57893f4da933/f0aff760-8431-11eb-9126-57893f4da933?token=TJpT2QZ1wODw6KLDzLLUKw&index=0

[stevefloyd]

Right. I moved around some work. This one works in Chrome and Brave: https://design.penpot.app/#/view/f0afd050-8431-11eb-9126-57893f4da933/f0aff760-8431-11eb-9126-57893f4da933?token=TJpT2QZ1wODw6KLDzLLUKw&index=0

OK, that one worked for me!

As I have reviewed what has been done so far, there is a lot I would adjust in way of design theory and UI. The core wireframe and functionality would not change, just some aspects of whitespace, typography, etc...

I like the logo and overall brand . The user flows and UI is clean and concise, it just needs to be further refined.

[berkes]

I've used figma and later penpot over Balsamiq here, but I should probably have stuck with Balsamiq (or Mozilla Pencil Project) to get wireframes lacking any design or visual identity.

At this stage, I feel, we should first get the flow, contents and ideas right. Both for the entire flockingbird and for parralel (or side) -projects such as this search. Which is what the current penpot designs should be read as (but don't communicate very well): wireframes.

IMO, the next step would be to poor this into a CSS framework (We've used Bulma for main Flockingbird) and use that for "design". IMO Bulma, or even Bootstrap is "good enough" for an MVP. Maybe with a few colors adjusted to match a logo.

A step beyond that, would be to really create a design, visual language and so on and implement that on Bulma (or whatever framework, if any at all).