Re: [GMG-Devel] requesting brain dump

[Christopher Allan Webber]

Hi Caleb,

Sorry it took me so long to respond to this.  I said I would, and so I am.

So I think there are two things at play here:

1) Extensibility, good defaults, negotiating design decisions, and
   how I try to balance my own views with someone actually making the
   contributions.
2) What happened with this tags issue specifically.

If you don't mind, I'd like to address #1 first, then talk about #2
and how #1 applies to #2.

How is MediaGoblin designed?
----------------------------

So first of all, the design of MediaGoblin is somewhere between a
specific design vision and an organic process.  What does that mean?
It means that before MediaGoblin started I had a pretty good idea of
what the project would generally look like.  As we've come closer to
part of each design being implemented how things will actually look
tends to look clearer... both to me, and hopefully to other
contributors, both because it begins to become obvious, and when not,
because we've talked about it and worked out a good solution.  (That's
also not always true.  Sometimes things seem like real head scratchers
for a while until someone comes along and points out the obvious (or
not so obvious but great) route.)  In other words, a lot of this
design comes from general project direction as was laid out early on,
and a lot of it comes from active communtiy discussion, especially on
IRC.


A contributor's say
-------------------

That said, we don't always have a clear vision for things, and I also
try to be conscious of the fact that the person doing the actual work
and implementation should have a significant amount of say in how it's
implemented!  If you are making it come to life, you're working
through the problem, and so your opinion on how things are working is
really of a lot of value here.  I weigh in a lot on things as they're
implemented... sometimes I'm pretty clear that things need to be a
certain way, but usually I describe what I think the vision of
something is, or if the contributor is actually going through the
frontier of things, I try to understand, evaluate, and then make
comments on that.

(Or sometimes it's not me doing it.  Or sometimes people are actually
commenting on things I write.  Actually we have a heck of a lot of
that, and if you hang out on IRC and read Elrond's posts you already
know that and know that it's something I appreciate greatly. :))

What happens if there's *massive* disagreement on things?  I actually
don't know for sure... we've been able to discuss most things pretty
well and a compromise or general agreement tends to be made.  Or, I
think so!


Good defaults versus extensibility
----------------------------------

A particular note needs to made about good defaults versus
extensibility.  This is a tough battle: obviously we want good
defaults regardless, but do we want *only* good defaults?  How much do
we want to allow people to configure?

Giving more configuration options means people will be able to have
instances closer to how they want them.  But it also means more
options to describe, more complex code to implement, and harder code
to maintain.  It's easy to add a feature (or configuration option).
Once people become accustomed to having it configurable, it's hard to
take it away.

When should we provide configuration options?  I think when it's a few
things:
 - It's of almost no cost for us to provide them.  For example, "how
   many entries per page" will pull either from a global variable or a
   config file.  It's no extra logic around it and pretty much the
   same number of lines of code to do it either way.
 - When there's a very clear demand for them, and providing them is
   clean enough to be worth the extra work.
 - When we think we can support them generally for a long time to
   come.

Thus my instinct is generally as much as possible we should be fairly
conservative in adding config options for now.  After a feature has
settled for a while, it'll be easier to tell whether or not adding
that configuration option is actually so useful.  (Now I don't think
this is *always* true... look how configurable we've made the storage
system ;))

Hopefully in the future we'll have a plugin system and that'll allow
for a *lot* more configurability without a bloated default base.  For
now, we don't yet.  Certain things will be configurable because it was
the project vision for these to be extensible (the storage system,
multiple media types), but other things we'll have to evaluate
carefully.  I'm interested in talking about them, but I think we need
to be very cautious.  Again, it's easier to add these things than take
them away.  We want MediaGoblin's codebase to be something we're happy
working in for a long time.


The tags issue specifically
---------------------------

Made it through this huge wall of text so far?  Great.  ;)

So the issue here, in sum:

Caleb was working on the tags issue.  Caleb did an AWESOME job of
implementing tags.  There was one disagreement, though we talked it
through: should we allow custom delimiters?  Caleb seemed confident
that he could implement it well, and especially really wanted
space-delimited tags as that's what he prefers.  I (or I think I did)
raised some concerns that maybe that could make things complex, but
Caleb seemed to think that he could get it working well.  So I
conceded and said he thought he could implement it, he should go ahead
and do it.  He did do it, it went in, and everyone seemed happy for a
bit.  But later on things ended up getting complex.

Basically formatting a string with helptext that's translatable that
explains "This is the tags field, tags are comma seprated" (or however
it was phrased) became complex because "tags are ',' separated" is not
as nice and not as clear.  We could limit the option to just tags or
spaces (Caleb mainly wanted this because he spaces) but there's some
complexity also in that the description's translation was marked
inside the form's class definition itself, so changing it on the fly
depending on the config file settings was actually simply not easy.

We actually still have the configuration option, but conversation
in-channel (including Caleb) seemed to indicate maybe that we'd change
it.  Regardless, even if you change it, the tag field's description
only mentions comma delimiting for now.

I'm not saying this is the optimal situation or that things are frozen
to this, but that's as far as I can tell how things are at and what we
discussed.


So what's the lesson?
---------------------

I don't want to extract a particular and exacting lesson here, but
instead have some points of reflection.

I'll tell you what *isn't right* and what I'm *not* trying to say:
that I know what's going on and everyone should listen to me.  That's
clearly wrong.  Caleb is often right when I'm wrong and I highly value
his views on things.  This is true for a lot of people in the
project... actually I think one of the reasons the project is doing so
well is because it's managed to expand far beyond just me.

And I still think contributors get a massive say in how things work.
They're doing the work after all, and are thinking about how it goes
together.  But we do also need to think about clear project vision, be
conservative about adding too many configuration options (for *now* at
least), and etc.  (And, conversely again, we'll want *some*
configuration options... again, we should just be very conservative
and careful about adding them.)

How to strike that balance?  Aside from loose ramblings from what's in
this email, I actually don't know for sure.  I think we'll need to
evaluate things as we go.  We've been doing that, and I think actually
we've been doing a pretty good job at it!  We're still learning
things, how to handle stuff like this right.  Or at least, I am.

I hope this email is helpful.  And of course, feedback is welcome. :)

 - Chris


Caleb Davis <address@hidden> writes:

> Hi all,
>
> There's something that came up in irc a few days back about why it
> would be tricky to accommodate ","- or " "-delimited tags as I had set
> it up previously. Specifically it came up when
> http://bugs.foocorp.net/issues/467 was going to be solved with a
> static description of the text field - "Tags (separated by commas)".
> Chris tried to explain to me why it would not work to just use
> gmg_globals in the media forms.py for dynamic text in the field
> descriptions. There was something about not knowing for sure that the
> globals were loaded by the time the forms were rendered during
> testing, but I don't recall anything else, and I still don't get it.
>
> My webdev skills were about a decade old until I started contributing
> to MediaGoblin, so I could be missing some fundamentals here. It's
> more important at this phase to keep the code clean than it is to
> allow luxuries like custom tag delimiters, but I am disappointed I
> didn't use a flexible design in this case. I want to get it right next
> time!
>
> Thanks,
> --Caleb
> _______________________________________________
> devel mailing list
> address@hidden
> http://lists.mediagoblin.org/listinfo/devel
>

-- 
The bottom line.