While we didn't have the slot count to fit @manas96's GSOC 2018 proposal for applying Gestalt's entity system library to Destination Sol over this summer we've seemingly got enough community activity to maybe do it as a more casual community project. I'd like to find out who might be interested in working with DS over the summer (and maybe further) in a more structured approach akin to a GSOC project.
The idea would be to roughly follow the GSOC guidelines only with a level playing field where anybody who could have qualified as a student or mentor can contribute. I'm not sure if there might be a primary Bureaucrat but if the interest and availability is there then sure why not. Somebody just needs to make sure there is in fact a weekly meet-up where some participants report back on what they've done, what they're planning, and how much time they have available over the next week or two. Bonus if we can also have a status write-up / blog to share with the world.
I'd like to hear from interested participants, feel free to post in this thread and/or talk about it on Slack. I've also set up a Doodle Poll to find a good time to get as many people together as possible by the next weekend to finalize the potential and maybe start planning out what should go on a GitHub Project Board. This might also be the ideal time for a recurring meeting - I expect only weekends will be viable for this.
To summarize my expectations of participants: make it to a weekly or bi-weekly meeting (or even just follow along really well otherwise) + have enough spare time to sign up for one or more tasks per period that would have decent odds for completion that period.
Potential differences:
We should still strive for quality, of course. IMHO it is OK to merge something that's functionally complete but not perfect (code quality, wording in comments, new feature with an edge case not yet covered) even after several rounds of review/tweaks. In that case I suggest submitting follow-up issues to not lose track of what remains outstanding, which could also be a good source of "Good First Issue" fodder for other potential new contributors
More on the project board
Initial board at https://github.com/orgs/MovingBlocks/projects/11 has 6 columns, here is my description and reasoning - again feedback very much appreciated. Similar/same approach as the GSOC projects, just with phases instead of months
Style of board is Kanban - the further to the right the closer to being worked and completed. That explains the perhaps somewhat odd placement of "Secondary ES Systems" as the second column in the list rather than 4th
The idea would be to roughly follow the GSOC guidelines only with a level playing field where anybody who could have qualified as a student or mentor can contribute. I'm not sure if there might be a primary Bureaucrat but if the interest and availability is there then sure why not. Somebody just needs to make sure there is in fact a weekly meet-up where some participants report back on what they've done, what they're planning, and how much time they have available over the next week or two. Bonus if we can also have a status write-up / blog to share with the world.
I'd like to hear from interested participants, feel free to post in this thread and/or talk about it on Slack. I've also set up a Doodle Poll to find a good time to get as many people together as possible by the next weekend to finalize the potential and maybe start planning out what should go on a GitHub Project Board. This might also be the ideal time for a recurring meeting - I expect only weekends will be viable for this.
To summarize my expectations of participants: make it to a weekly or bi-weekly meeting (or even just follow along really well otherwise) + have enough spare time to sign up for one or more tasks per period that would have decent odds for completion that period.
Potential differences:
- Two-week work periods instead of one-week due to the more casual pace? I'm leaning toward two weeks since anybody is free to submit PRs any time and multiple times per period if appropriate. That leaves an idle weekend between meetings to focus on work.
- Each person involved could take on a mentor role type title with its associated focus/responsibilities or do the work with the intent of "earning" that title by the end of the project (maybe for use as a formal mentor later)
- Less of a set schedule will mean more focus on an organized backlog with tasks of varying sizes. Likely no month type columns on a GitHub project board, more of a "phases" approach (foundation of ES, basic System implementation, secondary System implementation). We should be sure to focus on scope/estimates in items.
- Availability will differ per period- during the meeting participants should estimate how much time they expect to have then pick an appropriately sized task
- Anybody involved can review and merge PRs from other participants. Each will receive push access (I just added several already). I suggest one person reviews first but holds off from merging anything but trivial changes then a second provides an additional review and/or merges if the PR seems ready. Anything controversial should wait for more review.
- No GSOC style recognition or stipend, of course. More of a learning and community project. Maaaaaybe we can come up with some swag packages or something to hand out to survivors who stay active through the whole project, but that's less a motivator and more a cause for celebration at the end and making it more memorable
- When the project actually ends is more vague. Maybe a soft deadline in November before GCI starts, keeping in mind that a new project can be started again later. Or keep going till a set of target objectives have been accomplished.
- No evaluations but we could do a DestSol monthly play test / showcase to look at the progress. Maybe the 3rd Saturday each month?
We should still strive for quality, of course. IMHO it is OK to merge something that's functionally complete but not perfect (code quality, wording in comments, new feature with an edge case not yet covered) even after several rounds of review/tweaks. In that case I suggest submitting follow-up issues to not lose track of what remains outstanding, which could also be a good source of "Good First Issue" fodder for other potential new contributors
More on the project board
Initial board at https://github.com/orgs/MovingBlocks/projects/11 has 6 columns, here is my description and reasoning - again feedback very much appreciated. Similar/same approach as the GSOC projects, just with phases instead of months
Style of board is Kanban - the further to the right the closer to being worked and completed. That explains the perhaps somewhat odd placement of "Secondary ES Systems" as the second column in the list rather than 4th
- Backlog - relevant issues / cards for the project that either do not fit in a specific phase or hasn't been prioritized yet. Entry point for new things assigned to the project (if you look at an issue you'll be able to assign it to the project board - it would go to this column). Also good for misc/utility that could be done at any given time
- Secondary ES Systems - tertiary priority: conversion of non-essential or potentially tricky game logic to entity systems. Cannot be worked until prerequisites are implemented
- Fundamental ES Systems - secondary priority: conversion of essential game logic to entity systems and/or good candidates to learn from implementing first
- Base ES implementation - primary objectives for the ES implementation to even work in the first place
- In progress - PRs go here automatically. If somebody claims an issue/card please move it here (assigning an issue to yourself or referencing it in a PR might automagically do that? Unsure)
- Done - for completed stuff! Merged PRs and and associated closed issues will go here, can also manually move in stuff if appropriate