Figure out how to preserve post order for many-to-many relations like "Creator"

[Pomax]

While trying to implement persistent creator ordering for entries, @alanmoo and I came to the realization that we may have implemented "creators are a conceptually active entity" rather than just strings a little too early, and that there are a lot of open questions on how to actually make creators be meaningful "active" data. Based on discussions, we may need to rethink the concept of creators as more than just text strings.

One problem we uncovered is that there is no way to automatically resolve strings to pulse users. Especially for names that are not unique, someone needs to determine that the name typed corresponds to the user account for someone with that name, and we can't do that without either revealing personal information such as email addresses (which we obviously cannot reveal) so that people submitting an entry can verify that there is a user account for the creator they typed and it's the "right one".

Alternatively, we'd need to send notifications to users when someone posts an entry with a "creator" name that matches a user in the system, like an email with "someone just posted an entry to Pulse and your name matches one of the indicated creators. Please click here to check this entry, which will let you confirm whether or not you are (one of) the creator(s)". This doesn't feel like a very good solution either.

The "user posting this entry is the creator" is a thing we can actually track with a simple boolean on the Entry model (we already have published_by, so a published_by_creator flag is easily added)

Without a "limited community" backing for Pulse (think reddit or imgur) where users can know each other through comment/privmsg interaction (which I don't think we want to be adding at this point in time?) it feels like creators-can-link-to-users may be a concept too far for us to make a reality.

[jessevondoom]

Adding a couple thoughts without nearly enough context in the code itself...so here's an invitation to ignore me wholesale. But some thoughts:

• The relationship of user profile to project is the key, and it doesn't necessarily have to happen on project creation. We want to get users to the point where they want to interact with the system, so potentially we could build a mechanism for "I'm involved with this project" — either as a simple claim or even as a claim that needs to be approved by the project creator. But instead of making it a weird fuzzy match a la "someone just posted an entry with your name" we reverse it — the person claims the project and whoever entered the project can verify the person.
• I don't think we need to build something that's 100% backwards compatible or 100% active. What about an autocomplete function that gives options for matching profiles but falls back to a string if no profile is found? That would mean a lot of non-active data at first but that wouldn't have to affect user experience.
• This feels borderline shocking to type, but LinkedIn may give us some inspiration. They have interesting mechanisms here, like automatically adding a friend as a connection ONLY IF you know their email address. Never exposes it, but verifies more like one-way encryption. They also have interesting mechanisms for organizations and companies and how those link to individuals. May be worth exploring.

For now I'd say getting up and going with user profiles is critical, and we want to connect them to projects. But that could be anything mentioned above or even as lightweight as "favorite projects" without any formal oversight.

[Pomax]

Indeed, those ideas strongly hinge on having the kind of user profiles that social sites use with avatars, social media handles, and other such handy things that can can be used to verify that the person you're about to link to is in fact the person you should be linking to, without exposing sensitive information such as email addresses.

My main question here, though, is: "what are we doing?" @jessevondoom's suggestions are great if our intention is to invent an online community, but then it feels like we're not going far enough to enable that. If this is truly a site that should enable a community to pop up around it, then a reasonable expectation would be that it is the community's responsibility to determined what gets featured, rather than being told what the community should be looking at by a bunch of Mozilla employees, for instance. And that community members can comment on each others contributions, send messages to each other without needing to leave the platform, etc. etc.

Right now, Pulse is pretty much a syndication platform, with the potential to link users to entries but we never really settled on the "how" so that concretely this isn't something we can do right now. While I like the suggestions around achieving that "how", it feels like it's skipping over the more important "why", based on what we want Pulse to be (or what we want it to become).

[xmatthewx]

This is our moment for these questions and discussion, for aligning ideas. I hope that we use All Hands for this, and exit with a clear, shared vision.

MozFest proved that it's good to gather projects in a common space. This spring, we've validated that an ongoing stream of things is useful to the org, to build ambient awareness of the network. Now, we have the opportunity to figure out what this could be for the network itself. Fast forward to 2020: what's the most awesome/useful platform we can imagine?

We'll have a chance at All Hands to talk about this. Do some futurecasting as a team. For both Pulse and the Network site. We hope to create and rally around a shared vision with the whole team. From that, we can work backwards to discover the high-level roadmap, and figure out what we'd like to tackle over the next six months.

cc @kristinashu @mmmavis @alanmoo @hannahkane

[jessevondoom]

Agree that All Hands is the place to spend some time nailing these things down, but thought I'd clarify a little on people / users / community.

There's no goal to be a full social community with chat, regular posts, etc — but there is a stated goal to increase participation as well as bring the same kind of dynamic categorization we have for projects to the realm of "people" and to opportunities. People doesn't necessarily have to mean users.

Aspirationally: We want profiles for people in the network, expanded from what we have now. Those profiles are linked to projects and fellowship/grant opportunities, so as you see a project you can see people involved. From an open web fellow's page you can then learn about other open web fellows, the program, and how to apply. From that fellowship opportunity page you could see all open web fellows and/or projects they've worked on.

We can accomplish a lot of that with tags and categories in the short term.

Where people and users start to collide is in participation. How can we allow people to start adding their own profiles. Participatory actions in the people space like highlighting key projects, submitting news articles, and maintaining a profile blur those lines between people and users. Additional things like how we connect people to clubs, fellowships, and training that may interest them come into the picture a little. Add in project maintenance and there are legitimate questions around the best way to proceed.

We may want to focus on people profiles first and worry about merging with users later. But at All Hands we can lay all the things on the table, explore what options we have for participation and collaboration, then as the picture comes into focus we can dig into this more.

[hannahkane]

In addition to having our own goals, can we also answer the question about the value to the user? What is the user's mental model here - are they thinking of their profile as a public portfolio of their work? Are they seeing it as a kind of tool to report out on their projects (for example, for Fellows)? What is their incentive to create a profile and maintain it?

[xmatthewx]

Regarding incentive and motivation, we might break out 4 user types: staff, formal net member, emerging leader, established leader. Formal net member would include fellow, grantee, regional coordinator, mozfest wrangler.

We should queue up some conversations with a few fellows, mozfest wranglers, global sprint busy bees to discuss the platform and how it could serve them. I talked with a bunch of these people last year. It'd be good to repeat that more formally. Until then... some guesses and anecdotal insight:

• For staff and formal net members, the value to them intersects with the value for Mozilla ... it helps us give face to our work. It's also a chance for them to elevate their status in the network and get props for their work as creator or curator. We have 10 users that have added 14+ projects – they're big connectors and I know that some staff feel like this contribution is under-recognized. For creators trying to rally contributors, adding their name/face might increase recruitment. While we need to tap intrinsic motivation for longterm success, the profile could be a requirement for these two groups to help solve the chicken-egg challenge.
• There's potential value for an emerging leader. A profile with list of projects should add legitimacy for career development, similar to how a Github profile serves coders. We can also tie this profile into MozFest session facilitation, global sprint participation. I'd wager there's motivation there to get your profile in front of other people. And again, if you seek collaborators, contributors, funders, a profile on your project helps with the invitation.
• For established leaders there won't be much value at this early stage. We can ask for permission like we've done with the site/story engine, do the leg work for them.

[xmatthewx]

Let's clarify the deliverable @alanmoo @Pomax

[Pomax]

This is effectively an issue around "figuring out how to store the order in which data was posted", which is a general Django model problem not specific to Creators.

[Pomax]

@gideonthomas perhaps you can lend a hand here - I have tried several ways to get a Through model set up that links entries and creators, with the through model's row id being a reliable relative ordering, but no matter what I try to do in this code, DRF refuses to order entry.creators on the through model's id/pk field. Instead everything I try seems to reflect into the Creator instances instead, so I end up with a list that is correctly ordered by id, but using the wrong model's id, so the ordering is still very wrong.

[Pomax]

If you look at https://github.com/mozilla/network-pulse-api/blob/creator-order/pulseapi/creators/models.py#L42-L79 you will see a Throug model with a meta class that indicates ordering by pk of that model as far as I can tell, but using DRF to call, for instance, http://test.example.com:8000/api/pulse/entries/426/?format=json yields data like this:

{
"id":426,
"tags":[],
"issues":[],
"help_types":[],
"creators":[{"pk":197},{"pk":198}],
"bookmark_count":0,
"is_bookmarked":false,
"title":"title 2",
"content_url":"http://example.com/approved",
"description":"",
"get_involved":"",
"get_involved_url":"",
"interest":"",
"featured":false,
"thumbnail":null,
"created":"2017-08-23T00:10:02.921574Z",
"published_by":"Pomax",
"moderation_state":3
}

In that, the creators list shows a list of creators ordered by Creator.pk, not OrderedCreatorRecord.pk...

[xmatthewx]

Is this resolved by #190 @Pomax? Or still an open discussion?

[Pomax]

this was resolved.