Noting code concerns in advance of design work

Clearing the Path
1

Here’s the example case:

Where should I mark code considerations? In this case, wanting to be sure that when a user changes email, it stays associated with their same Discourse account…

If the answer is: “No worries, the SSO handles it fine already”, then we’re done in this case. But if the answer is that we have to include that as a requirement… I guess it could make sense to make a US in the design issue so that the US is a spec the coding considers. Or maybe there are cases where we have code and design issues open simultaneously, especially in cases like this where some of the code work can be done in advance of the design…

2

Thanks for the question. If it weren’t such a big question, it would be simple to note concerns in the code issue, the way msiep has done on recent examples. This present question, however, calls for the extra steps to the process I laid out but seem to have forgotten to record. Briefly, this issue needs to be discussed in a backlog grooming session before even getting to the step of wireframes and mockups. The backend concerns make it a much bigger project than the UI changes might suggest. I’ll schedule a meeting.

1 Appreciation
3

From the Discourse Discourse:

Discourse will validate that the nonce is valid, and if valid, it will expire it right away so it can not be used again. Then, it will attempt to:

  1. Log the user on by looking up an already associated external_id in the SingleSignOnRecord model
  2. Log the user on by using the email provided (updating external_id)
  3. Create a new account for the user providing (email, username, name) updating external_id

Closer to the top of that page is says that Discourse uses email to associate Discourse users with external users, but, the quote above suggests that the external ID is what’s used to identify the user.

1 Appreciation
4

Back on topic, I guess the question is how to, while discussing here general ideas about some work, how/when do design folks make sure to check with code before going down some design rabbit-hole (and vice-versa: coders shouldn’t get into working on something design actually thinks shouldn’t happen or should happen differently from their perspective…).

I think one answer is that even though a topic may be focused on dev or design, the “invite” function here should be used to ping people to check out a topic where their input is requested.

An additional possibility: create some extra groups to make it easier to @ mention groups to draw attention to things (could be abused though, be careful with too many groups and pinging too many people too often). Note that tagging of users is a nice idea but not possible right now (e.g. in our case, we could tag people as “Haskellers”, that link shows some options though, like using badges, which might be useful still).

I welcome further thoughts from others, but overall, it seems we just keep the general idea of checking-in with relevant people, using our best judgment, case-by-case.

5

on the topic of this example I gave, I opened GitLab issue snowdrift#95