Choosing a name

For those of you who have been following my progress lately on django-developers, that title probably makes some sense. For the rest of you, I’ll explain. I’ve been working on on a project for quite some time now, with the goal of eventually being accepted as a contrib app in the official distribution. Trouble is, nobody (myself included) likes the name as it stands: django-values.

Essentially, it’s an attempt to encourage separation between programmers and managers with regard to certain values that are management-related, rather than technology-related. Since I’m not using standardized terminology (I don’t know if there even is any) I’ll attempt to illustrate the difference by describing a few situations of each.

As you can see, technology values can reasonably be stored directly in code, because they won’t change. They’re dependent on mostly immutable forces like the storage type of a basic text field, the numeric capabilities of a 32-bit processor, or basic rules of time calculation. In order for management to change any of these, they’d have good reason for calling in a programmer, because a lot would have to change in order to implement any changes.

Management values, on the other hand, are those that have no relation to any technical limitations, but instead simply impact the logic followed by the application. These may change considerably more frequently, and with extremely little impact on existing code. Unfortuantely, since they’re used in code, they’re generally stored in code too, so changing them still requires a programmer. In some organizations, this can also mean the application has to go through a round of testing before being deployed to the public. That’s a lot of overhead for something that really doesn’t even have a code impact.

To make a long story short (too late!), I decided to write an app for Django that allows programmers to define placeholders for management values and reference them in Python as if the actual value had been defined explicitly. Then, management can come in and define or redefine those values as they see fit, without requiring any programmer interaction, or even a restart of the application.

As you can see, this isn’t an easy thing to describe, much less slap a name on. There have been a few suggestions so far, but they were all accompanied by a disclaimer, such as “I call them {{ name }}, but that doesn’t really make any more sense than ‘values’.” So I’m appealing to a greater audience, with hopes that somebody out there has a better way to go about this.

Please help me name my app!

Comments

  1. At 1:08 p.m. on May 19, 2007, SanPy said ...

    adminvars?

  2. At 3:06 p.m. on May 19, 2007, Jaap said ...

    What about "technical rules" vs "business rules", or "technical configuration" vs "business configuration"?

  3. At 7:25 p.m. on May 19, 2007, Az Nach said ...

    You must have thought about this yourself, but what about clauses?

  4. At 5:03 a.m. on May 20, 2007, Anonymous said ...

    The word you're looking for is "fulcra" which is the plural of fulcrum, aka the hinge point. As you are picking the point where one side ends and the other begins, this seems most logical to me.

  5. At 1:19 p.m. on May 20, 2007, Sebastien Fievet said ...

    confmanager ?

  6. At 4:35 p.m. on May 20, 2007, Anonymous said ...

    settings

  7. At 5:09 p.m. on May 20, 2007, Anonymous said ...

    django.contrib.options

  8. At 8:49 p.m. on May 20, 2007, Marty Alchin said ...

    @ SanPy: "adminvars" does hit a bit on the app's intent, but I'm not sure about it yet.

    @ Jaap: I'm not sure what you mean. Are recommending I change some of the wording in my post, or is there a name suggestion in there?

    @ Az Nach: I don't know what you mean by "clauses". I don't see a definition for that word that makes sense to me for this app.

    @ Anonymous (a): While "fulcra" would indeed be good if this were designed to manage the very idea of separation in general, that's not really the point here. It does somewhat describe part of how the app works, but it provides no description of what it really does.

    @ Sebastien Fievet: I had considered some variant on "conf" but there's already has a "django.conf" package, and I don't think it'd be good to reuse that name for something completely different.

    @ Anonymous (b): Similar to "conf", Django uses "django.conf.settings" to manage the variables set in settings.py, and it would be quite confusing to reuse this name for something entirely separate.

    @ Anonymous (c): I'm using "options" for part of the app already, based on some feedback from django-developers, so this may well be a start. I'd like something a bit more specific if possible, but it's on the list.

  9. At 1:38 a.m. on May 21, 2007, Nicholas said ...

    Constants? Even though they're not necessarily going to remain the same, it's the kind of thing you typically use language-provided constants for.

  10. At 3:28 a.m. on May 21, 2007, apollo13 said ...

    @Nicholas: Constants could misslead some users, I don't think it would be a good idea...

  11. At 6:23 a.m. on May 21, 2007, Marty Alchin said ...

    @ Nicholas & apollo13: There was some discussion about something like "dynamic constants" to try to use that existing idea of oncstants, but still make sure it's clear that they can be changed. However, I fear that would still be misleading, as those two words are still quite contradictory.

  12. At 7:39 a.m. on May 21, 2007, Kr0n said ...

    If I understood well, you're trying to separate "technical constraints" from "business constraints". Am I wrong?

    The term you mentioned can't find maybe is related to this: business domain, business restrictions, and so on...

    just my2c ;)

  13. At 10:11 p.m. on May 22, 2007, jim said ...

    sootnobs

  14. At 6:32 a.m. on May 24, 2007, Anonymous said ...

    'sitepolicy' or just 'policy' ?

  15. At 7:37 a.m. on May 24, 2007, Marty Alchin said ...

    Policy! That's exactly the kind of suggestion I was hoping for. It's concise, yet accurately describes the goal trying to be achieved. Once I get a new version done, I'll put it to django-developers and see what feedback it receives.

Speak up!


This particular article was posted on Friday, May 18, 2007, and has received 15 comments.

It was followed by Offline Django?.

It contains the following links:

Archive

Categories

Powered by Django.