Add optional URLs for individual members

[ertgl]

On the Individual Members page, only members' names are currently listed, with no distinguishing URLs.

At a minimum, providing a few optional URL fields, similar to GitHub's approach, could fill this gap. Members could link to personal websites, social media, or other contact addresses.

This would also help highlight content created by the people behind/around Django, make the community/ecosystem more approachable, and help newcomers (whether to the core or to the community) connect with the others more quickly.

The Mastodon post also describes the motivation behind this, providing both feedback and a feature request.

[adamchainz]

+1 from me, as long as we can make the URLs opt-in and under each member's control. I think we don't currently give members any kind of account.

[ertgl]

Thank you @adamchainz. If the idea gets approved, I can work on it with ~medium priority.

[JohananOppongAmoateng]

@adamchainz is it possible to use the forum accounts and write a cron job or something to once in a while get the links and update

[adamchainz]

Yeah, using the forum could work, but we do have open registration on djangoproject.com: https://www.djangoproject.com/accounts/register/ . So perhaps to minimize confusion, it would be best to be that account.

[ertgl]

Yeah, using the forum could work, but we do have open registration on djangoproject.com: https://www.djangoproject.com/accounts/register/ . So perhaps to minimize confusion, it would be best to be that account.

I'll review the code accordingly and prepare a report with my findings, while keeping an eye on this issue for new comments.

[ertgl]

Here's the summary of observations and what we need to decide next.

Overview

Quick reference for refocusing:

1. The endpoint /accounts/register/ is handled by registration.backends.default.views.RegistrationView.
2. The registration package comes from the django-registration-redux library.
3. The project doesn't customize the registration profile model, it uses registration.RegistrationProfile.
4. RegistrationProfile has a one-to-one relationship with the settings.AUTH_USER_MODEL via the user field.
5. The endpoint /foundation/individual-members/ is handled by members.views.IndividualMemberListView.
6. The view renders djangoproject/templates/members/individualmember_list.html.
7. The data source is members.IndividualMember model.
8. IndividualMember does not currently relate to AUTH_USER_MODEL.
9. IndividualMember has a mandatory email field.

Proposed Changes

10. Add an optional one-to-one relationship on IndividualMember to AUTH_USER_MODEL, named as user.
    10.1. Use on_delete=models.SET_NULL to preserve membership records if the user is deleted.
    10.2. Keep email mandatory.
    10.3. Linking by email is possible but I don't recommend.
11. For adding URL fields we have two possible approaches on IndividualMember:
    11.1. Add n URLFields (e.g., 5, similar to GitHub).
    11.1.1. URLs can be displayed vertically with texts (and optionally icons), or horizontally with icons.
    11.1.2. Optionally, add a CharField for URL content (e.g., page title).
    11.1.3. Optionally, add a CharField with predefined choices for URL type, to map icons and ALT texts.
    11.1.4. Optionally, implement URL-specific parsing (e.g., one for the registry of Mastodon server domains, one for X links, etc.) for consistent display.
    11.2. Or, add a single general-purpose URLField.
    11.2.1. Apply same display rules as above (under 11.1).
12. Create a members.forms.IndividualMemberUpdateForm, inheriting from ModelForm.
    12.1. Use IndividualMember as the model.
    12.2. Define editable fields (name, email, links, etc).
13. Create members.views.IndividualMemberUpdateView, inheriting from UpdateView.
    13.1. Use IndividualMemberUpdateForm.
    13.2. Override the get_object to filter by request.user.
    13.3. Create template, djangoproject/templates/members/individualmember_form.html.
14. Define /foundation/individual-members/edit/ pointing to IndividualMemberUpdateView.

Next Steps

1. We need style guidelines for consistent display (I can try my best, but the team should set the complexity level, since it will guide the rest of the implementation).
2. Accordingly, add URLField(s) and the helper fields (if any).
3. Link IndividualMember to AUTH_USER_MODEL.
4. Create the update form, template and view.
5. Edit the list template.
6. Verify accessibility.

[ertgl]

A few more thoughts:

We could also create a DetailView and include the links there, along with the other public information. This way, we wouldn't need to modify the list view, except for converting the list items into links.

If the idea and plan are welcome, I'd be happy to submit a PR for review.

[thibaudcolas]

👋 just so you know the site does already have "user profiles", here’s mine: /~thibaudcolas/. This is tied to the account you use to contribute on code.djangoproject.com, and I believe also used to add RSS feeds to the site.

[ertgl]

👋 @thibaudcolas, thanks for the context! This simplifies everything. We can now link list items directly to the existing profile pages you mentioned; no need for new detail or update views, forms, or templates.

Next, we need to:

1. Ensure we link only to existing profiles.
   1.1. To reverse the URL, we need to specify username parameter.
   1.2. We can still create an optional one-to-one relationship from IndividualMember to AUTH_USER_MODEL.
2. Decide on the implementation complexity, including the number of URL fields.
   2.1. We can keep it very simple (one URLField for general use). However, a few sample options are listed under 11.1.1 on Add optional URLs for individual members #2243 (comment).

[sarahboyce]

Note that this issue strongly relates to/duplicates this issue: #1738

[ertgl]

Thank you @sarahboyce. It really looks like we've reached a connected point here.

Updated summary: The main topic of this issue is allowing individual members to specify their own URLs. While exploring the most authentic approach, we aligned our path with #1738. As far as I understand, everyone (who has provided feedback there and here) seems to agree on implementing #1738. So, this issue is now dependent on it. However, we haven't yet reached a final decision regarding the URLs.

Since this is my first time contributing to this project, I'm not sure where the threshold is for opening a PR. Please don't hesitate to let me know if/when I can assist.

[sarahboyce]

I think there has been enough positive feedback that PRs are welcome 👍