[Job board] Conversation thread + notifications on job offers

That's a lot of different new modules. :-)

I'll list them before handling any estimation, to be sure of the scope:

Search by "localisation"
- What is localisation? I see on "Post a new offer" that it's only a text field, should this select list every entered values by every users?
Filter by Type d'offres
- Communities implementation
- Sharing feature implemenation
- Archive implementation
- "Mes offres" is what I created?
- What if I check "Toutes les offres", should it un-check other check boxes ?
FAQ module
- Are they static?
- What's behind them? :)
User tags ("Capitaine", "Associé"...)
- Only one per user?
- Where do I manage them?
Module file attachement
Module conversation (The thread feature)
- What does the little smiley on the right mean?
- Mentions to others on the conversation thread
Refine offers creation/modification
- Intermediate page for "Public" or "Private" project - may be only some css/js tricks to manipulate the form
- Localisation feature
- "Conditions de la mission" - What are the list of possible values? Static? User defined? Where?
- Styling on description field
- Sharing feature (Private offers only)
  - Targets? Users + Tags + Communities?
  - What does that mean to target a tag?
  - What does that mean to target a community?
    - Only allow to see?
    - Send a notification?
    - Send an email?
    - What if I remove someone, should they no longer be able to see it?
    - Should it remove the notification too?
"Offre privée @Happy Dev Paris"
- What does it mean? As saw on creation/modification, I can target many people/tags/communities, which one should be shown?

Sorry, I meant Conversation thread + notifications. I understand the description of this issue led to some confusion, but I "only" meant those two parts.

Ok,

So, conversation thread: Was already partially implemented, if we keep the same experience (no @user, only comments on threads) should not be long to add it ; it'll need some styling too, we may be able to gather everything in 3-4 days I guess. I let @gaelleM confirm.

Notification, hard one, specially on the job board. There are some different definition though, which one is requested?

Options

Local only

A new job offer is posted on HD Paris, as an user of HD Paris I want a systematic notification

Server to server subscriptions

A new job offer is posted on HD Paris, as an user who will see this offer on their app, I want a systematic notification.

The HD Nantes - Subscribe > HD Paris part is based on the LDP Sources of HD Nantes.

I want notifications based on my skills

This one may be the simplest one from an user perspective: I have a skill & I turned on notification ; boom.

This behavior may be based on the work of Calum for backlinks but with different kind of activities ; there are still some holes to fill, like "What if I add a server to the LDP Sources of HD Paris?" and "What if as a User I want notifications for JS x Paris but not for JS x Casaco?"

Sources by users

(:-)) I believe that both subject can be linked, it solves the last question right above for eg. it also avoid the need of server to server communication to subscribe to something, I can send my request directly from the client.

@jbpasquier I agree with what you've just presented. I had made the same journey on my side.

I'd leave aside the "subscription to a given skill" for now, thinking we can use the user's profile directly to know which skills does she want to be notified for.

Then my understanding is that the only missing part is the back link to a given community, when a community subscribes to another's job board, so that the latter can publish its notifications appropriately. Correct?

We're using sources here in a way there aren't really made for. That feels sketchy but... maybe we're cool with it.

I'd go for the "let's notify everyone that has a relevant skill on her profile in a community that has subscribe to my job board" version. What do you say?

I voluntary ignored the community implementation on my previous message because it adds a layer of complexity and still have some unknown.

Community x Notifications have some nice & blacks points:

The cool

We have a list of users to reach, the server on which the community exists will be aware when a job offer is posted on this community & who it can notify.

The less cooler

Communities still have some conflicts with sources. On a complete implementation of communities and a way to manage them on app, in many case sources may be useless ; sources will be use only to post resources & to fill ranges/search options.
The server will not be aware of which skills are on this job offer and may not know the skill list of users.

Solution

A more-or-less aggressive way to notify like that:

Still, I believe that we can't avoid this kind of behavior on a completely decentralized world.

About the eventual performance impact, this definitely needs an async queue.

Fairly clear.

Why do you say: The server will not be aware of which skills are on this job offer and may not know the skill list of users.?

@balessan @sylvain What do you think?

The server will not be aware of which skills are on this job offer and may not know the skill list of users.?

If you take the schema right above, the posting user is on HD Paris server, the job offer will be on HD Paris server, but the community is on HD PACA and users are on three different server.

HD Paris server will not be aware of what are skills of those users, it may also not be aware that these users are part of the community HD PACA.

I get it. But then the HD Paris server is aware of the list of skills of the job offer, no?

Regarding the list of notified users, I understand the HD Paris server is not aware of its content but... is it a problem? Why do you consider it "less cool"? :-)

Yes it is.

Because we need a complex way to notify users. We can't simply say "Ey, my job offer is Quidditch, John from Miami and Helen from Troy do Quidditch. I'll notify them." We need to make the information flow step by step until the user itself. And in our case, we'll even notify users who don't care about Quidditch - still it'll not generate any notification.

we'll even notify users who don't care about Quidditch - still it'll not generate any notification.

Hmmm... My understanding is that we just assess their list of skills to determine if they should be notified, no?

But Paris don't know their list of skills. PACA neither.

Hmmm... how do we determine who gets notified then?

That's the solution proposed above. :-)

The user themself, that's why I call it "aggressive". But even if it adds some noise to the server to server communications, it's something that should work on any disposition, it let the user decide by themself of what they want to be notified about. Even if in the Hubl case, our package decide for them.

The list of skills should definitely be the same

It's been a long time since I've worked on this module. If there are no new additions, most of the styles should be finished. The delay seems reasonable to me.

assigned to @alexbourlier

@jbpasquier HD Paris might be willing to fund this if it is in their budget. Improving this component is their priority. They want notifications + a conversation thread below each offer, a.k.a. this issue.

Are we missing some info to put a price on it?

In my head we don't, even though we need communities live to have notifications here.

Maybe we can split this issue:

Notifications: One issue per type of notification they'll need, with "When should this notification should be sent", "Who should be notified" and "What to notify"
Conversation thread. With a scope: Ping users and smilies are new features, maybe we can implement it in two time.

@rachel What do you think?

Definitely. They can be release separately so I would also choose to do 2 different issues. It would allow to go deeper in the specs as well. It's still unsure on my side how to test those features.

I agree

@rachel No rush but just to be sure: you're on it, right?

@jbpasquier Once the issues are all cleaned up, we'll need estimations on them as Happy Dev Paris requested it and were willing to invest on them. Let's leave tokens aside for now. There are some unanswered questions that will be dealt with next week during the coliving session.

@alexbourlier actually I'm not sure I have all the info, and you were assigned so I completely forgot about it. Good that you've pinged me. I can create them, but can you tell me however what kind of notifications are wanted? It's not clear from the discussion above. Only a notification from a job offer posted on a community I belong to? When we say "notification" we mean within the UI + email? Within the UI, when is the notification read? As soon as I land on the job board?

Also for the conversation one I understand they are 3 issues:

I should be able to comment on a post. What happens when I do? does the creator get a notification?
I should be able to ping people. Can I ping people outside of the community? This links to the conversation here: #770 (closed) and #769 (moved)
@jbpasquier is speaking about smilies... can someone point me to where this was discussed? Where should emojis be displayed exactly?

@jbpasquier is speaking about smilies... can someone point me to where this was discussed? Where should emojis be displayed exactly?

Mockup https://invis.io/3POVGBKAQD8#/328712388_NEW_PROJECTS

I guess one issue is about receiving in app + email notifications when a job offer is posted. That implies backlinks from my joboffers sources.

That's a good question regarding when it is read. I would say when I access the job board yes, unless @jbpasquier says it will be a massive pain to switch that to switching notifications as read when I access the detail view of each job offer.

Maybe we can discuss it orally if that is easier

unless @jbpasquier says it will be a massive pain to switch that to switching notifications as read when I access the detail view of each job offer.

No, no, that's fine :-)

Woah it took me ages to find the smiley on the mockup! I didn't expect it to be on the left I think. thanks!

Yeah I think a quick call to get over the question would be good. Also next wednesday I'm not available before 5 PM But I'm moving this on the chat so we can find a time

mentioned in issue #790 (closed)

Closing in favor of #853 (moved) and https://git.startinblox.com/management/product-owners-sync/issues/1

closed