ID Dashboard 2.1 improvements: Next Steps

First off, congratulations to @plypy on being selected. It was a really hard choice – very, very strong proposals.

Now next steps:

  1. see @michael’s post on this matter
  2. refork the repo as I made a mess, but things are tidy now, let’s not work off of master unless we need to! :smiley:
  3. Let’s schedule a time to chat @plypy and discuss priorities with the project – I have some ideas of stuff that needs to be done @michael and @elliott should also chime in with their ideas as well.

I will make a more detailed post later but I wanted to just get the ball rolling.

1 Like

I have begun to assign tickets to you on JIRA which I want done as part of GSoC. Let’s plan to have a chat so we can prioritize these tickets and set up milestones. I’d at a bare minimum like to have better test coverage. Either you or myself will finish up the UI improvements.

Thanks for all your warm-hearted notes, I’ll check these things.

As for the works, we could start it ASAP, but let me first clear my pile-up homework :weary:.

We could set the chat time about next weekend(9/10th May), so I can prepare more details.

You can’t start working yet – this is the community bonding period – which means you can clear your pile of HW – as you don’t need to do much prepwork as you know the codebase :slight_smile: The only things left are prioritizing and setting up milestones.

@plypy, I created a branch which we will use for all work related to GSoC 2015. We’ll merge n the changes at the end.

Let’s concretely plan (either here publicly – or off-line in e-mail – either one works. I would prefer voice…I want to make sure that you are successful and that we have a clearly defined end-goal of the summer and then break it down.

Things I see as high priority (in no particular order other than recalling from memory):

  • Remove all frontend dependencies from git and opt opt to use bower for managing those
  • Improve our test coverage, if we have a function in the frontend, we should have a test covering that functionality.
  • We should have CI running for showing the status of our builds and whether or not tests pass. We could use Travis CI.
  • I merged most of the contributions from our Google Code-In students, but the sign-up page is not merged as I did not like the way it looked. We need to ensure that the page doesn’t suffer from reflow bugs as I resize my browser…that’s bad in my eyes. Validations could also use some TLC…and that part is influx…
  • Bring our code up to par and use Code Climate – bragging rights for all involved. We shouldn’t have any dependencies hosted in our git – everything should be installed via npm or bower.
  • Get rid of Less and move to Sass. I’d love to see us migrate away from Bootstrap in favor of using Bourbon Neat, in combination with the mixins provided by Bourbon. Check out Refills and Bitters for some nice patterns and scaffolding done with Bourbon and Neat.
  • With regards to the above point, checkout node-sass, node-bourbon, node-neat, node-refill.

I think that’s it for now – I feel like :burke:@burke – I seem to be doing what he does and pile on ideas…Some of this extends beyond the scope of GSoC – just improving test coverage alone is a project onto itself.

I’m having a final in this Saturday, so pardon me for the short response.

I’m very willing to see more tests and better coverage and anything others could ensure a good code quality.

However, as for migrating from LESS to SASS and bootstrap to bourbon neat, I’m not that supportive. IMHO, these things are just tools, unless they could really bring us some huge real impact, say tens of better features and a few must-have, we don’t need to spend our time on that. What’s more LESS seems to be a natural partner in node project. But as I don’t know much about frontend stuff, you might have more insights on these.

And also you seem to forget those backend changes, as we put earlier,

  • use keystone.js to provide a better and robust project structure and admin tools
  • remove MySQL dependencies
  • refactor some ugly legacy code
  • build robust error logging mechanism

Again, IMHO, a strong backend support is much more important than frontend. After all, we are the centre ID provider of the community.

These are a few of my opinions, you may take them into consideration. And let’s discuss more over voice, I’ve sent you an invitation via gCalendar.

:+1: for admin & logging tools!

Signed, Your Users


1 Like

Also just as a reminder, they most important “user visible” thing that IDD could do that it does not do today is automatically create and update accounts through the Discourse API when an account is created/updated in Dashboard.

This lets us see and @ mention all users in the Discourse user directory since they are effectively “synchronized” … a big missing piece today!


Ah, yes – other things…as I said – this was from memory and my memory appears to be bad…The others are nice to haves. Re: Less to Sass – I’m holding firm on that…if it’s not done by you – I’m going to do it myself after you complete your project.

I can support this as goals. One thing I want that is a freebie essentially is convert to bower for frontend dependencies (our dependencies are a nightmare as of right now to manage – and they don’t belong in git) and have Travis CI provide us some insight into the status of our builds/tests passing. Code Climate is a freebie, so you need to do nothing there.

I’d like to add this as a “nice to have”

Similar nice to have :slight_smile: If @plypy doesn’t write it – I think i will.

Our most important user facing feature is more than nice to have, it’s critical for the community.

If we aren’t able to get it done in GSoC, we’ll just have to find another way to get it done. :slight_smile:

It will probably not take long to implement. I plan on talking with @plypy this weekend. There’s a list of things I want done (in addition to what’s proposed – if he doesn’t do it – I’ll do it myself – either way it’s getting done :smiley:) We are going to set milestones for midterm evals.

1 Like

Don’t worry, the Discourse thing is in my agenda with high priority. Hopefully, it will be done first.


The things I proposed kind of fall under clean up legacy code stuff. I forgot the keystone.js stuff…but those are things that if you don’t do them…I’m going to do it – either way I feel strongly…basically we have enough work to keep you busy – and if at the end stuff is not done…then I will do it myself.

Very excited about modernizing and extending this tool that we all use every day. Looking forward to seeing the first draft of the plan! :smile:

I am too – I can’t wait to see the awesome work that @plypy will produce this summer!

In preparation for our chat on Saturday, I have created and closed some of the GCI changes which I merged already so we have a clear idea of what’s done versus what needs to be done.

@plypy, I have assigned a handful of tickets to you. We need to prioritize them but I created an epic on JIRA which links together all the v2.1 tickets earmarked for GSoC – if we don’t get to them all, that’s not a failure, but I think we will.

1 Like

Had a chat with @plypy about milestones and we organized our tickets into milestones

Midterm eval milestones: Final eval milestones:

If he finishes those ahead of schedule – I have more work.

NB: Added a badge to our README.

@plypy – let’s work with pull requests and use feature branches so I can review each task.