Project: Associate & Happy Dev Paris

Associate must be defined

@alexandre Should Happy Dev Paris & Associate be dynamic? For now, should we make a simple field on database as for the Business Provider?

changed milestone to %Projects part I

Happy Dev Paris label is probably the name of the client app. We use it on the OIDC permission page in the question: Do you allow Happy Dev Paris to access xyz?. Should be reusable I guess :)

Associé label can be fixed for now.

Their values should be part of the Project model, making it even more Happy Dev specific...

@sylvain @balessan: an opinion here?

By Alexandre on 2020-01-08T09:10:58 (imported from GitLab project)

@sylvain, @balessan: UP :)

By Alexandre on 2020-01-08T09:10:58 (imported from GitLab project)

I disagree Happy Dev Paris is the name of the app. If I display the project with another app, the 5% don't go to the same company? :)

I don't get your last point.

@sylvain, @balessan : Are we saying Happy Dev Paris should be set by project, and stored on the Project model?

By Alexandre on 2020-01-22T16:28:00 (imported from GitLab project)

I guess so. Everytime you start a project, you want to define which company is going to sell it. Right?

I guess for now this can be a clone of the BusinessProvider model?

name = models.CharField(max_length=255)
fee = models.PositiveIntegerField(default='0')

If so, let's rename BusinessProvider as Contribution and use it for Associate, Happy Dev Paris, Business Provider, Anything Else...?

Probably the most flexible approach yes, hence probably the best.

By Alexandre on 2020-01-23T06:06:20 (imported from GitLab project)

Some design questions have come up from working on this @sophie @jbpasquier @alexandre @rachel

Currently Contributors exist in the mock-up like this: https://projects.invisionapp.com/share/3POVGBKAQD8#/screens/332923048

We discussed that from a back-end perspective it's better to have one Contributor model, which could be a collective, a business provider etc depending on the server, and on the project.. this would change the UI design so that it was more flexible/generic, and involved more connecting forms. I've drawn up a mock-up to show what I mean:

Does this make sense? Can I make this change?

Shoudln't we have a call here to settle the issue?

By Alexandre on 2020-02-07T10:37:11 (imported from GitLab project)

I'm available :)

@jbpasquier, @balessan, @sylvain: Who is in? When is it happening?

By Alexandre on 2020-02-07T20:51:39 (imported from GitLab project)

I spoke about it with @jbpasquier today. Not sure I am concerned but let me know.

My guess is that the only thing left is for @sophie :)

I might be wrong, and it might be obvious for everyone but me, but the question here is: how do we architecture that feature so that it works in a federated way.

I'd like at least to have your GO @balessan on the solution proposed by @calummackervoy, so that we are all on the same page that this works in a federated world, and that it is the right way to architecture it. Then there is a UX question indeed, but that's not the core of the discussion I believe.

By Alexandre on 2020-02-11T21:13:38 (imported from GitLab project)

I'd like at least to have your GO @balessan on the solution proposed by @calummackervoy, so that we are all on the same page that this works in a federated world, and that it is the right way to architecture it.

This is the first time the word federated appears in that discussion, so I am not convinced it is still related. Anyway, if you create dedicated Contributor and ContributorType models, you should then be able to use the federated sources mechanism to properly source the data accross your federation when needed.

Need some testing though. What do you think @jbpasquier, do you see any limitations ?

But asking the question clearly before proposing a call would sure help everybody understand the exact topic :-)

Same question as for skills: Shouldn't we use Dbpedia for the contributor types?

@balessan Sorry, I thought the topic was clear. And as you said, maybe it is obvious and discussing it some more is just a waste of time. I just think that for the first cases of federation in such models, I'd feel more comfortable knowing the framework team validated our choices. It can be quick I believe.

So... call tomorrow at 5pm?

By Alexandre on 2020-02-11T21:31:17 (imported from GitLab project)

Shouldn't we use Dbpedia for the contributor types?

At least for Skills it bears some value to share a common list so that we are searching for the same thing. Here it looks like a label, I don't think it has to be shared between instances.

What do you think @jbpasquier, do you see any limitations ?

I don't see any. As long as we give proper permissions on that ( https://git.happy-dev.fr/startinblox/djangoldp-packages/djangoldp/issues/197 )

If it is just a label, why use a model? Why not a simple string?

@sylvain To have a consolidated view later on, like "Here is the list of projects of Happy Dev Paris" or "Here are the projects that owe you a finder's fee".

By Alexandre on 2020-02-12T09:13:06 (imported from GitLab project)

In that case, it's not a label, it's an agent. We should probably use a User for that.

Ah ah, when is the call to settle this down then? :-)

By Alexandre on 2020-02-12T09:45:48 (imported from GitLab project)

I am struggling a bit to follow here and bring answers.

Generally speaking, I think we haven't worked yet the UX of the federation in detail. This prototype was designed at the time for the Happy Dev Paris community and the federation aspect of it was not considered so much. So now that the project evolved, there is probably a need to work the UX of the federation. We have talked about it this morning with @rachel and will dedicate some time to it soon.

Cool.

By Alexandre on 2020-02-13T16:14:21 (imported from GitLab project)

I spoke to @sophie about this.. There is a balance here for it being easy to make a project (e.g. in Happy Dev use case, I always want these 3 types of contributor to be included), and flexible (e.g. I may be paying third party business provider's fees)

We discussed having another model ProjectConfiguration, so that above "Add a contributor" in the project-edit form I can select a configuration "Happy Dev Project" which populates the form with 3 contributors of type Associate, Collective, BusinessProvider

En plus, when I try to think about this in a federated sense it gives me a headache..

• It seems wrong for each federation to have its own copy of identical ContributorType, but inflexible to hardcode these, or to have a central server storing ContributorType and ProjectConfiguration
• If I create a local Happy Dev Paris Contributor instead of referencing Happy Dev Paris' version, then it will be treated as a different object, and later when I access the view with all of Happy Dev Paris' projects, I will actually only receive a subset depending on which copy I submitted (maybe the collective is implicit in which server holds the project)

This is probably best discussed in a call? @balessan @jbpasquier @alexandre @sylvain @rachel ?

Arf... Sorry for some reason I see this one just now. I really screwed up with Projects for many reasons:

• We should not have prioritized it. Today only Happy Dev is asking for it
• The mockups are very Happy Dev centric, and it gives you headaches :)

I see two ways out of this: a.) We do simplify the mockup like crazy, but a Project ends up being a Circle, and then what's the point of shipping Projects at all, let's just ship Circles and job done. Project will come later on. b.) We ship Projects later on

To make matters simpler, it is now @rachel's call to prioritize the roadmap wisely. I just wanted to express clearly here how I feel about this feature. I'll see with @jbpasquier and @rachel what makes sense for us now. Let's do damage control :-)

We could also ask HD Paris to pay for this.

Do we have an idea how much work that would require?

I was also thinking something along that line.

We don't know yet but we will soon regarding time estimates and budgets.

I was also thinking something along that line.

We don't know yet but we will soon regarding time estimates and budgets.

It seems wrong for each federation to have its own copy of identical ContributorType, but inflexible to hardcode these, or to have a central server storing ContributorType and ProjectConfiguration

We can still point every client to the same source. Or create a "federated" source containing only one server. Like we'll do for skills.

If I create a local Happy Dev Paris Contributor instead of referencing Happy Dev Paris' version, then it will be treated as a different object, and later when I access the view with all of Happy Dev Paris' projects, I will actually only receive a subset depending on which copy I submitted (maybe the collective is implicit in which server holds the project)

Don't do that. :) Maybe we can add some js candy "It already exists on your federation" or something like that.

We discussed having another model ProjectConfiguration, so that above "Add a contributor" in the project-edit form I can select a configuration "Happy Dev Project" which populates the form with 3 contributors of type Associate, Collective, BusinessProvider

I'm not sure to understand what the purpose of ProjectConfiguration?

I'm closing this in favor of the new MVP for projects: https://git.startinblox.com/applications/sib-app/-/milestones/25

closed