Users make public contributions. Therefore each user has a public presence. While this is not a social networking site, it is a social site, so participants need a way to identify each other and get to know a bit about each other.
What information does the site show about a user:
On every post.
A user-specific page.
MVP analysis:
Login methods: TBD. We don’t need Facebook integration and 2FA on day one, but whatever we do needs to be secure.
User names: need to be in MVP. Non-unique names please (I really appreciate that on SE). Impersonation is very rare in practice.
Avatar pictures: nice, most platforms have these, but not absolutely needed in MVP.
Profile page with a free-form box: not needed in MVP. I expect this to come soon after, but it isn’t needed in the MVP.
Tracking other users’ activity: not needed in MVP. It’s of dubious value for purposes other than moderation. It is useful for moderation so it should come at some later point.
Activity log for the user’s own sake (which may be public if it doesn’t contain confidential information): needed in MVP. It doesn’t need to be nicely formatted, but as a user, I often do want to find posts that I’ve recently interacted with. I miss this all the time on Github (what pull request did I comment on yesterday?).
Associating a profile with a Stack Exchange profile: not an MVP feature for a QA site, but maybe an MVP feature for a QA site designed to migrate from SE.
Additional optional profile fields to consider including (again, not sure which to consider MVP):
Website - Many users want this either for social or professional reasons
Email address - I’ve seen many profiles where this is included indirectly “my name at website that you see elsewhere in the profile”
Preferred Pronouns - It is, for better or worse, becoming common in many other contexts. Arguably a Q & A site may not need such a thing, but if people are going to put it in plain text in their profile (as many do in SE) then there logically should be a place for it. This is not to mandate any use/non-use of pronouns, styles of writing or anything else - purely to provide information for those who want it. For many (probably most) users it will irrelevant, which would be argument for this to not be MVP. But including it here for (civil) discussion and because adding 10 fields may be as easy (practically speaking) as adding 2 fields and easier than adding more fields at a later time.
Isn’t there a GDPR issue with pronouns? I thought that’s why SE isn’t creating a profile field for it. (I don’t know either way; this is a question, not an assertion.)
@cellio I have absolutely no idea! It actually had me a bit baffled - if pronouns were such a big deal, why not have a field? But since SE management hasn’t said much of anything meaningful…but I digress.
All I really know about GDPR is that some wonderful little web sites that I used to use a lot have basically gone offline because they did not want to deal with GDPR compliance (not against GDPR, just didn’t want the hassle/expense involved for a tiny homegrown low budge project).
No issues with GDPR with collecting pronouns, as long as they’re freely given - they must not be required information, but if we have a field that folks can fill in if they wish to, that’s fine.
Website, email, Twitter, Twitch… that’s absolutely not MVP. People can include it in their free-form profile if they want.
Pronouns: that must not ever happen. Encouraging people to make personal information such as gender public is not great in the first place. When non-standard becomes an option (i.e. anything other than M/F), it’s a very bad idea. Having a gender field not only encourages others to treat people differently based on the indicated gender, it also makes it easy for hate criminals to target their victims.
@cellio It’s not about GDPR. All GDPR says is that 1. if you store someone’s personal data (such as gender or pronoun preference), you must let them know on request; and 2. you must let them change it on request.
@gilles I’m perfectly fine with not including an actual Pronoun field. I think it is an important issue for consideration. I am among those who am perfectly fine with “write in a way that avoids pronouns” for a site like this (when I explained to my evil twin about what codidact is after I registered it and explained that a pronoun controversy was part of the SE problem (he uses SE occasionally but had not noticed the current controversy), his first comment was that quite a while ago he learned to “write in a way that avoids pronouns”). If the consensus is "leave it out and let people put in in their profile text if they care about it, that’s fine with me. But I think it should be considered primarily because I don’t want to have to revisit the issue again in the near future.
If we give people a free-form text box, they can put whatever they want in there – email address, web site, pronouns, favorite pizza toppings… we don’t have to care. Later we might add some of those as separate fields, or not. (I’d say yes for web site, maybe for email address, and no for the rest, but we don’t have to decide now.)
I have always been a bit baffled by the way SE handles multiple topic sites. I understand the “have to really ‘connect’ with a new site”. That makes sense. But it seems that the profiles are the same except when they’re not. This leads to quite a bit of confusion. For example, when I changed my profile picture, it did not necessarily (I had the option) change across all sites - that just doesn’t make sense to me because if someone pulls up my profile they see all the sites I am on, so why have differences?
In addition, there are issues (just saw one recently but don’t remember the details) regarding removing one site profile (i.e., disconnecting from a site) vs. removing all site profiles, and other issues. It seems to me that within a Codidact instance, which can incorporate multiple topic sites, each user should have exactly one profile. That profile would be associated with one or more topic sites. If a user wants to be disconnected from a site, then that would just need one database change to make the disconnect (a little more if content is to be removed, etc. of course). If a user wants to make a change - picture, text, etc. - it would always be for everything. If a user is suspended for some reason, that could be easily applied to either one site or all sites, depending on the rules in place and the particular problem, equally easily as there would be one profile record pointing to all the currently connected sites.
Basically: Let’s make this work the way (I think) the average user would expect it to work and not (as I think it currently is) the overly complex SE way.
If someone with more experience with SE can explain how/why it is the way it is (and perhaps why we should to), I am open to discussion.
I disagree with that. I think there are many reasons why people would like to have different profiles on some sites (e.g. with more sensitive topics). Therefore I think the following would be a better idea:
We have one (network-wide) master profile. Every other site profile is kept in sync with that one.
However you can choose for some profiles to be distinct (opt-out). You can change them and the change will not propagate to the master profile and vice versa. However once you turn the setting on, the site profile will be synced with the master profile and all prior changes lost. It could be possible to “force push” (in programmer jargon) the unsynced profile to the master profile.
Why not extend that to something like Reddit flair? It’s effectively displaying a tiny piece of information on the site, which would be a slightly more effective means of communicating it than hiding it in an about page, but in a way that doesn’t explicitly require pronouns. Flair can be use used for a lot beyond just pronouns, but I’m not sure if that goes too far towards pushing a slight social media approach (but tbf, even GitHub has something similar with statuses, which kinda deviates from the raw concept of GH. Same with GL). I’m not gonna lie, I’m entirely out of the loop (just discovered the effort here yesterday, so I have a lot to catch up with), but if it wouldn’t be too horribly misaligned with the proposed goal of the new site, this might be worth considering.
Definitely not MVP though.
While I have to agree with this, you really need to consider the depth of what you’re saying. Pretty much anything that is unique can potentially be used to target abuse by <insert some metric here>: about sections (explicitly stating gender for an instance, either directly or indirectly by writing in the third person - take CommonsWare for an instance), gendered usernames (i.e. mine), some people use their real names as usernames, external links have an even greater potential of revealing a lot, especially if it involves other people. Ever re-used your username somewhere and used your real name in combination with one account? Not to forget profile pics.
There’s always going to be pronouns in some or another form. Taking a laid-back approach with flair lets people who want to have a field like that have one, but also gives an embed use for any other piece of tiny, social media-like piece of content. But yeah, it’s not MVP and would exist alongside an “about me” section that already solves the problem. The usefulness is of course up for debate, but it’s a way of solving the “problem” in a way that isn’t exclusively to solve the “problem”. The concept of flair is a pretty flexible system.
Different sites are different communities. Why should I be forced to appear in exactly the same way to everyone? This isn’t Quora.
I want to be able to have different profiles for different communities. This ability doesn’t need to be present in the MVP, but it needs to come some time.
On Stack Exchange, I’ve had different profile text on different sites, limited mainly by the fact that it’s very inconvenient:
I want my profile text to be in the language of the site.
If I’m a moderator on a site, I want to say so in my profile.
On some sites I want to add a little information about my background that’s relevant to the site.
This is true for me for the “about” text as well. Before the current crisis I had customized that text on several sites to include stuff relevant on that site but not globally. (I haven’t changed other fields per-site, but people do.)
I agree customization isn’t MVP, but I’d like us to have it eventually. And ideally it’d be a lot easier to manage than it is on SE today.
OK. @cellio and @gilles you have made your points. So the solution then is to, essentially, build a system that includes:
Master User record - username, authentication, email (i.e., for admin/notification, not public), etc.
System Profile - with all the decided upon features - image, text, whatever specific fields we agree to include (which can change over time)
Topic Site Profile - exactly the same as System Profile except for a “Use System Profile” flag. If the flag is set then you don’t get to edit anything else in that Topic Site Profile as the system will read everything from the System Profile. If the flag is not set then you can edit each Topic Site Profile separately with the option to copy the changes to the System Profile (which in turn would be shown on any Topical Sites where you have set "Use System Profile’. Done well, this should be very simple to use, and should not be hard to code.
If sites are structured hierarchically then profile setup could be a lot easier. I’m thinking something like
Tech (Like SO)
Programming
Code Review
Code Golf?
*nix
Ubuntu
Art
Writing
Photography
World Building
Language
Esperanto
Russian
Spanish
This is not too well-thought out, just tossing an idea. The benefit then would be that you can change your “tech” profile, then go one level deeper and set a custom one for *nix only, then maybe change you “arts” profile.
I’ve been thinking about site organization lately, and the distinction between tags and sites in SE is not optimal IMO. SO is a monolithic beast, which would probably benefit from splitting at some level like “Java ecosystem” site, “.Net CLR ecosystem”, “Databases”, “Web dev”, etc etc etc.
On the other hand, overly fragmenting communities so early on is a double edged sword. On one side, it means that reaching critical mass in any one place is harder, but on the other, theres less noise to contend with. If we live-import all SO Q&A activity to a single stack, but have a community of C#ers, then they risk being drowned out among all the imported questions. If they are only contending against questions in a single tag, and we selectively go bringing in tags on request, then it would be less troublesome. We don’t need to be importing every single Erlang question if we dont have anyone on Codidact who cares. (sorry Erlang, not dissing you, its just an example)
Do users really want/need multiple levels of different profiles? I’m fine with one for all sites (as already stated), and I can see how someone might want different profiles for different sites. But a full hierarchy? I can tell you from experience this tarts to get overly-complex-for-little-benefit pretty quickly.
Okay for the MVP I agree, keep it simple. I still feel that SO is monolithic, but this is not the place to discuss it. It feels like the equivalent of having a “Religion” site and just throwing all of them in there indiscriminately.
Agreed. Hierarchy builds in a much larger level of complexity especially if we’re going to look into ranking by “reputation” (whenever we decide that concept). Speaking of reputation, that sounds like the perfect topic for a new thread. Incoming!
I think the issue of SO being monolithic is a separate issue. The primary issues for the MVP, I believe, are the design issues of the software - what features should it include, how do those features work, etc. While “having multiple topic areas within one system” is a MVP feature, which areas should be included and the actual division of information/Q&A/etc. into those areas is not, IMHO, a software design/development question. It is an important issue that should be explored (and then decided) in parallel to software development - but in the end it does not actually change the software.
It kind of does, in a subtle way regarding question import. Question import has so far been considered necessary in the MVP, and if we need a mechanism to import tags or tag groups as sites, we need to develop and discuss it before we can use it. This belongs in MVP: Data import - #7 by cellio, so I’ll continue there.