Hi Folk,
Last night was great. It was encouraging to see folk interested in working on a project together.
For folk who didn't come last night. Hopefully you will notice this and participate. If anyone has folk that they feel comfortable sending an email to directly so that they are aware of the discussion, that would be great.
Basically we are going to see if there is a project that we can work on together this year in order to provide some continuity from month to month and a chance to learn from one another in the context of a real thing.
If we find a project that enough of us are willing to work on, we'll spend the first 15-20 minutes of the hack night and lightning round meetings coordinating or working on the project. On nights where we have a formal speaker like next months meeting with Eileen, we won't focus on it at all in order to give the presentation our full attention. We'll probably just end up using github and issues to coordinate mostly anyway once we get into it.
The value we should get out of it is that by focusing on one project over time we'll be able to learn from one another more quickly when we get together because all the background and context of the code will be shared over many meetings.
The most important challenge will be finding or conceiving of the right project.
I'm thinking that it should be well balanced with a network aspect, some ui aspect and the potential for something meaty on the language front, but I might be wrong about that. It might be best to just choose a library like treat that's pure language level brain candy to keep things simple, fun and interesting. Any thoughts appreciated on that would be great. Everything will depend on folks level of interest.
A Process
Lets spend a few days suggesting ideas through this weekend and discussing their pros and cons so folk have time to do some searches and share their thoughts.
Then early next week we'll do a poll. Each person giving a score to each suggestion.
Each score should have three parts
A pass/fail grade where a pass means that it would be worth 15-20 minutes of each hack night and lighting meeting to touch on the project.
Whether you might be interested in putting an hour or two a month towards such a project
Whether you might be interested in putting in more than 2 hours per month on it (in theory and as your schedule allows).
Then we can look at the interest and figure out which way to go
Let me know what you think
Here are some options that I like
----------------------------------------------------
Discourse
----------------------------------------------------
A modern bulletin board with a rails back end and an ember front end.
Pros:
-----
+) It's a significant and finished project.
+) It's 100% open source
+) Any level of experience with it might be useful to anyone. Just getting familiar with installing and running it might be worthwhile.
+) It's got project management and technical infrastructure already in place, so we wouldn't need to do as much project management and setup.
+) Different folk can even focus on different parts as their interest leads, while still allowing us to learn from one another.
+) Since it's an extensible system we could just focus on creating a plugin together.
+) It uses a modern javascript framework that should be of interest to most ruby programmers.
Cons:
-----
-) It's a big project, so setup and gaining familiarity with it might take more than something we create for ourselves.
-) The more real a project is the more you tend to have to deal with practical issues that might not be any fun. I don't know yet how challenging it is just to get it set up and installed to work on.
-) I'm not a fan of infinite scrolling, though maybe this would be an opportunity to fix that by implementing a fix to what I dislike about infinite scrolling (that you can't use the scrolbar to figure out where you are in the conversation).
----------------------------------------------------
A Casual Card Table
----------------------------------------------------
I've always wanted to create a casual card table that does two things. Model the mechanical process of playing cards rather than the specific rules of any one game, and add audio chat to it.
Most card games model the rules of individual games, but if we were to first focus on the mechanics, drawing a card, flipping it, giving it to others, putting it on the table or on a stack, then we could have a card table that could play most card games.
And the real reason for playing cards is to have something interesting to do while you talk with your friends.
Such a project would have some interesting technical aspects, still not be very difficult and open the door to other, interesting language based tasks like ai-bots that could be interesting for some time.
Pros:
-----
+) The domain is simple and familiar to everyone
+) There is a graphical side, a server side, an opportunity to do some interesting language work like ai-bots and a realtime network aspect to flex the presence and channel features of Rails5
+) even with all these dimensions it should still be easy to implement as a small project.
+) There is plenty of room to extend in the future, chips, scoring, rule sets for specific games, strategies.
+) Personally I love cards and would have no trouble pouring a lot of time into a casual card table.
Cons:
-----
-) There would be more work setting up and managing the project, but I really wouldn't mind doing that at all.
-) I have a lot of experience with audio chat in general, but implementing it in the browser could be a real technical challenge. It might end up needing to just use text chat or requiring specific browser versions.
-) As you can see in just my description, there are a few different ways we can go with this, so we'll have to coordinate on scope in order to make sure that it doesn't veer away from what folk thought it would be.
----------------------------------------------------
Treat
----------------------------------------------------
Treat is a natural language processing toolkit for ruby. Natural language processing is pure brain candy and something that Ruby should really excel in. It's also a practical tool and one that should be useful in the coming years as folk do more with voice input systems.
There is more detail here
https://github.com/louismullie/treatPros:
-----
+) It's pure language, so there would be fewer distractions from things like graphics, network hosting and frameworks. That might make it more fun for the experts and easier to get into for new folk.
+) The author has a clear list of ideas to be implemented already outlined for us
+) There seems to be a lot of research to draw from and low hanging fruit to bring to ruby in this area.
Cons:
-----
-) I'm not really sure what stage it is in.
-) Since it is so language focused it might become something where it's harder for the sysadmin and graphics/ui oriented folk to contribute as much as the language experts. At least in the beginning, we can expect that those of us who are newer to the language will probably have our code edited a lot to be more idiomatic, as they say.
This would be fun and instructive for us, but might prove a drag for the experts? If we do something more well rounded then the sys admin and ui folk will be able to offer more in return.
Anyway those are my thoughts. I apologize for the length.
I'd love to hear what you folk think.
-Cort