Proposal #12: LiquidFeedback, Ruby edition

[oliverbarnes]

https://github.com/oliverbarnes/liquidfeedback-ruby

I've recently started this rewrite in ruby of LiquidFeedback, the democratic participation platform. It's just starting to pick up steam, and it'd be great to get more people involved.

If you're interested in how software, the internet and open source can change politics and society, this is made to fit for you :)

Technology-wise, you'll practice/learn how to build APIs with ruby, and front-end apps with ember.js, following best practices.

Since the project is in its early stages, you'll have a strong impact, and see how software grows from early beginnings to an alpha stage. I can use help on everything from extending the code-base (adding new endpoints, working on internal business logic like processing of voting delegation) to designing the web interface and discussing user scenarios.

I'm happy to mentor and/or coach. I work as a full-time mentor at my day job.

Also happy to spend a good chunk of time collaborating presentially, if you're in Berlin, London, or another major European city. Planning on traveling there this summer.

If you're curious and would like to read up on Liquid Feedback, liquid democracy and the concepts behind them, I suggest you get this book out: http://principles.liquidfeedback.org (it's short, and well written).

Update

Regarding the project plan and team application:

It’s hard to predict which specific features will be on the plate when the SoC begins, given the project’s early stage. Things are changing fast.

What’s clear is there’ll be lots of work on user-facing features, broadly, as opposed to now, where only the API is in the works. User facing features will involve both the interface (design and front-end dev) and API updates to accommodate them.

We’ll plan out the work together like an agile software shop: fleshing out features in [user stories and scenarios]([1] http://www.mountaingoatsoftware.com/books/user-stories-applied), breaking down tasks and assigning them, and working in weekly or bi-weekly iterations. This would be a good introduction to agile development processes for you as well. And we’ll be doing TDD throughout.

Examples of user stories that may be worked on would be:

Citizen votes on an issue
Citizen delegates their vote to another citizen on an issue
Citizen posts issue
Citizen posts initiative
Citizen comments on initiative

Part of this process will be analyzing the original LiquidFeedback, mapping the way it works and defining how we’d like it to work (improving it, in other words).

[thestubborndev]

It's a great idea :-) let's talk about this project 👍

[KatiRG]

I'm happy to learn about this too and am pairing with @thestubborndev. Looking forward to hearing more!

[helenemartin]

I live in London

[oliverbarnes]

@helenemartin thanks for your interest in the project! So far @thestubborndev and @KatiRG are looking to pair in Rome. They contacted me over email and we might do a google hangout some time later this week, you're welcome to join us. Please shoot me an email when you get a chance (oliverbwork at gmail dot com), telling me about your experience with Ruby and web dev in general, and your interests

[svenfuchs]

@oliverbarnes (ohai oliver! :) @helenemartin just so you are aware ... projects can accept multiple teams. Each of the teams would send in an application. The best rated applications will be selected. Only one application will be selected per project. Likewise, teams can send in multiple applications for different projects, one application per project. Obviously only one application per team can be accepted. All the details should be here: http://railsgirlssummerofcode.org/students/application. (The only limitation is that teams shouldn't mix amongst each other.)

It's in a project's best interest to work with multiple teams on their applications ... because this raises their chances that one team/application will make it and work will actually be done during summer.
It is also in a team's interest to send in applications for a few projects, because this raises their chances that at least one will be accepted.

Otoh preparing an application means a lot of work, and teams should make sure to prepare their application(s) as thoroughly as possible to raise their chances.

[helenemartin]

@svenfuchs , I am a bit confused, so I would send an online application for each project?
A colleague of mine who did Rails SOC last year said she really worked hard for one application, breaking down the task on excell sheets.. I can't really see myself doing this for each project :?

[oliverbarnes]

@helenemartin I was a little confused too. Been reading up on the application guidelines and on the rgsoc google group (http://goo.gl/IN5b67), it's making more sense now.

I think a good next step for you would be to find a pair to work with you on the project. People have been posting for pairs on the google groups. You'll already have a mentor for this project (myself), and I can help you and your pair with the application. Not sure if I can be both mentor and coach, I'm assuming it's better if there's another person for that. I would post for a coach on the google group as well, and ask about devs in London willing to be coaches. Ideally there'll be a sponsor company there making their office available, then you'd be all set - pair, mentor, coach, office, application.

I'd guess it's easier submitting the subsequent applications after you do the first too, you'll have a template.

[helenemartin]

@oliverbarnes Thanks for your email. I already have a pair and potential coach for Memorizr(proposal 5) The creator of this open source is also the mentor, but me and my pair will apply for several projects to maximize our chances! Best wishes

[oliverbarnes]

@helenemartin awesome, you have a team already then :) Let me know if you all decide to apply for this one as well, and I'll help where I can.

[helenemartin]

@oliverbarnes Ok! will meet my pair on Wednesday

[svenfuchs]

@helenemartin sorry, i didn't mean to say that you have to apply for all projects. from what i remember from last year most teams would apply for a single project, maybe a few teams for two, or so. you are right, preparing an application is a big amount of work.

[helenemartin]

@svenfuchs I never intended to apply for all of them! :) I really only have the time to concentrate on one!

[svenfuchs]

@oliverbarnes @helenemartin about the coach, that's right. it ideally should be a person (or a team of coaches, taking turns) that you can sit at the office with. or at least someone who you can meet with in person daily or so. the "mentor" in rgsoc terms is a project domain expert, who can be located remotely. see http://railsgirlssummerofcode.org/about/roles/ for all the roles

[KatiRG]

@svenfuchs there is no section in the RGSoC application for mentors to fill out anything, but if @oliverbarnes cannot be a coach (due to location away from pair) then is it the case that he does not have to write anything in the application? He would be the person to go through the Project Proposal with, yes?

[svenfuchs]

@KatiRG yes, that's right.

@oliverbarnes knows the project, and he should give directions about planning the work on the project (e.g. start by doing A, then pick either of B or C next). He should be involved during summer in reviewing your progress. In terms of project management the "mentor" (project expert) takes the role of the "project owner".

Your coaches on the other hand know you, and will help you learning and getting the actual work done during summer. Which is why they should help you to prepare the application.

[oliverbarnes]

@svenfuchs currently I'm helping them out in understanding the project, sending them resources to get them up to speed for it (stuff on APIs, emberjs, etc), and in preparing the application... I guess I'm over-stepping my mentor/project owner role, but it's just naturally going this way. Hope it's cool to have some role flexibility, without being an 'official coach'?

[svenfuchs]

@oliverbarnes absolutely :)

[oliverbarnes]

@svenfuchs we're working on the project plan here. Creating a set of milestones and tasks months in advance seems to go against the very idea of agile planning ;) Wouldn't a set of general goals and a methodology be enough?

[helenemartin]

@oliverbarnes Do you know coaches, places to work in London(we are approaching as many people as possible)? We are thinking of applying for liquidfeedback as well as Memorizr. Let me know. Best wishes H

[svenfuchs]

@oliverbarnes it depends a lot on your project, and team. of course you can't define daily, or maybe even weekly tasks. that works even less for newcomers. but depending on your project you might be able to define a list of (tiny to bigger) features that you'd like to see implemented along with a certain order, where the team would then pick from depending on their progress.

During the selection process the committee will try to understand how well prepared the project is and how clear a picture the team has on what they are going to do during summer. Of course, depending on the project this might mean different things.

[oliverbarnes]

@helenemartin I don't, unfortunately. But the first company that pops to mind when I think of the UK is ThoughtWorks, a huge reference in Ruby-world. RGSoC sounds just the kind of initiative they'd support, and in fact googling them brought up a Railsgirls workshop they held in India last year.

I'd try contacting them for both coaches and an office. Going to ping them myself over twitter

[oliverbarnes]

@svenfuchs is this draft going in the right direction?

As project owner/manager, I'd really like to avoid a watefally backlog, given the state of early and rapid change. But let me know if we can add anything towards showing preparedness

(@KatiRG)

[svenfuchs]

@oliverbarnes Yes, it does.

I see, your project can't really define a lot upfront because the state of the project at the beginning of July is unclear. There are other projects that have the same issue.

This is generally fine, although please also take into account:

• Please talk to your team (or teams, should there be more than one who want to apply) about their skills and experience. Ask questions like if they know what a JSON API is, etc. The entire purpose of Rails Girls Summer of Code is to act as a long term learning goal for participants Rails Girls beginner workshops. As in "I'll continue to learn for a year so I'll be well prepared for next year's RgSoC". That means typical students won't be as skilled as you'd expect that from a junior developer. Otoh, some students who completed last year's RgSoC then found a job or an internship as a junior dev. I am only saying this because coaches and mentors tended to expect too much from students.
• You can't necessarily rely on much prepartion getting done before the program actually starts because we can only pay students for 3 months. We should probably remove the point "Preparations" from the timeline on http://railsgirlssummerofcode.org. This is meant as "general preparations", also from our side. Obviously you can talk to your team though, and ask them to read a book or two. The workload listed seems somewhat steep to me for a beginner. Instead you can also plan for some initial learning phase starting July. Don't put too much into it, there'll be dragons :)

All that said ... if you could define two or three example stories or features that could be implemented then that would be great. Don't worry if these can't be "reserved" for your team.

Does that make sense?

[KatiRG]

@zonpantli @akash01 bringing you in the loop

[oliverbarnes]

Thanks @svenfuchs, it does - very good points. We are talking carefully about the skills needed, and might move some of the preparation stuff into the SoC time itself. Definitely won't expect junior dev level yet, trying to think of them more like students at Bloc (the mentoring program I'm working at), on their way to that level. Will work closely with them to get them up to speed on what's needed.

[oliverbarnes]

@helenemartin in case you haven't seen it, have a look and feel free to use and increment this project plan we're working on and discussing with Sven.

[helenemartin]

@oliverbarnes sorry for late reply. I will look at your increments.I have gathered my pair got in contact with you

[amencarini]

Hello @helenemartin, @oliverbarnes! I was pointed here by @svenfuchs.

The project seems really interesting! I'm based in Central London and I'd be happy to help with coaching! I'm also gathering a few more engineers at HouseTrip to join the effort.

Please let me know how I can be of most assistance at these preliminary stages.

[helenemartin]

@amencarini Hey Allessandro! Great news! I know someone working there, a woman supportive to Rails Girls. Would you want me to liaise with her? or not?

[helenemartin]

@amencarini do you want to meet up fairly soon?

[amencarini]

@helenemartin we could have a quick introductory chat sometime this week and take it from there. Let's move the organisational details to email: [email protected]. Cheers :)

[mnive93]

Me and my partner @Vishya find this project very interesting and would love to be a part of it this summer. How do we proceed further with this?

[tracymu]

Hello, my partner @catherine-jones and I are located in Sydney, Australia and have office space and coaches here available to work with us. We would also like to apply to work on this project as part of RGSoC.

[oliverbarnes]

@svenfuchs one concern raised by a couple of applicants has been about submitting similar project plans, given this reference project plan I've been putting together jointly with the different interested teams, and suggesting they use to facilitate the process for all involved.

My understanding is the teams will be selected and matched to projects based on their skillset, interests and preparedness (including having good coaches and infrastructure), and relevance of the open source project itself, rather than competing team plans. Taking into account that newcomers wouldn't be expected to have experience with planning software projects, and that importance of feature or backlog picks are relative things... Specially if the backlog is very likely to change by the time the SoC begins (and in this project's case, if there isn't a clear backlog yet).

So if they have similar plans it's ok, the important thing would be that it's a viable one, and then their team's attributes would be the differentiators.

Is this a reasonable interpretation? Please let me know if I'm missing something here, this seems to be the main sticking point before they can submit their applications.

cc @KatiRG @Qianfinland @helenemartin @amencarini @emilycoats @tracymu @catherine-jones