mediagoblin-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GMG-Devel] December 3rd, our monthly IRC meeting!


From: Christopher Allan Webber
Subject: Re: [GMG-Devel] December 3rd, our monthly IRC meeting!
Date: Sun, 04 Dec 2011 13:51:24 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Hey Aaron and anyone who wasn't able to attend, here's the meeting logs:

http://mediagoblin.org/irclogs/irc_meeting_2011-12-03.txt

I'm going to comment inline as summaries of what we also discussed.
But first the big news, and I've reordered your email to put it first:

Aaron Williamson <address@hidden> writes:

>>>> Possibility of an SQL Database Backend? 'executive summary' (well, you
>>>> should read the long docs): "We could move to sql. It's probably replacing
>>>> one type of pain by another type of pain, but those are somewhat 
>>>> comparable.
>>>> Leaving the main question: Do we want to occupy our main devs for some long
>>>> time with this task and loose momentum?"
>
> Even with a feature as simple as "favoriting," I've struggled with NOSQL. This
> is doubtless partly due to my inexperience with it, but it doesn't help that
> when you read the MongoDB docs on NOSQL data modeling best practices, the 
> answer
> is "there aren't really any yet." It's hard to find good examples. So for me
> personally, this is impeding progress, but obviously if moving to SQL would
> hamper federation or take enormous effort, that should be taken into account.
>

The big news is that yes, we're moving from MongoDB->SQL.  This won't be
trivial, and we know it.  Basically the plan is:

 - Over the next month, make the models and etc work, and refactor the
   codebase a little bit to make moving to SQL next month easier.
   We can tackle all of the starred tasks here without actually starting
   to switch the codebase:
   
http://wiki.mediagoblin.org/SQL_Database_Backend#SQL_switch_tentative_action_plan

 - Next month, furious work on a branch that's fast-tracked for merge to
   convert the whole codebase to SQL.

>>> - The concept and naming of "favourites". We'll (hopefully) be able to
>>> "favourite" media soon, which I *think* means that 1) it'll work like
>>> a "I like this" comment, a quick token of appreciation, 2) it'll be
>>> added to your list of favourites so you can save and promote it, and
>>> 3) we could maybe use the number of favourites as a ranking. What I'd
>>> like to know is: is that the intended purpose? If so, should we name
>>> them favo(u)rites or something else? "Like", "love", "save",
>>> "appreciate", "heart", "high five" and many more could all be
>>> contenders. And the name should be consistent with the action and
>>> purpose, of course. So I'd like to clear up how and why we will use
>>> favourites and what we should call them.
>
> "Favorite" is probably wrong, though I'm the one who started us down that 
> path.
> I have a soft spot for "heart" because it's internet-speak-y and could be
> represented with some version of a "<3" which I think contributes nicely to 
> our
> geeky branding. "Love" is over the top, and "Aaron loved this picture" smacks
> both of the past tense and the physical act of love. "Like" is a bit Facebook,
> but is maybe my 2nd favorite. "Appreciate" is too impersonal.
>

We actually discussed this a bit.  None of these are amazing options,
but I think "favorite" is actually the best one.  It's pretty impartial,
and it poses no facebook-like "Where's the dislike button?" issue.  I
think we're going to stick with favorite, but maybe the icon will not
say that (as it already currently doesn't).

>>>> We plan to create a plugin system. Do we want to create that soon or push 
>>>> it
>>>> off until things settle a bit more? (Willkg 08:54, 10 November 2011 (EST))
>
> I'd prioritize federation over plugins.
>

Agreed, and we talked about postponing plugin stuff for a few months but
to keep it in mind.  Will Kahn-Greene has experience with building
several plugin systems so we'll probably lean on him to put together
thoughts on what this looks like when the time comes.

Actually our meeting got very overwhelmed with a lot of things and we
didn't have time to talk about goals for the next month aside from the
SQL stuff, but I think we should really start pushing federation forward
full-throttle.  There's also no reason we can't do this in parallell to
the SQL stuff.

>>>> Feature Ideas: What should we do about the wiki page? Keep it and have it 
>>>> as
>>>> a monthly topic for "what next"? Convert everything to long waiting bugs?
>
> No opinion.

We discussed this.  There's a new category for issues on the tracker:
"Future idea", so it's okay to put feature requests that we haven't
committed to on the tracker.  There's a "Exclude future ideas" query:
http://bugs.foocorp.net/projects/mediagoblin/issues?query_id=6

> Sorry again that I can't be there. Have a great meeting!
>
> Aaron

Thanks, this is going to be an intense couple of months.  Hopefully we
can have some good momentum to plow through this as cleanly and
efficiently as possible!

 - cwebb


reply via email to

[Prev in Thread] Current Thread [Next in Thread]