Assembling the team

[WildWeazel]

As much as I'm enjoying catching up on this week's technical progress, we need to discuss administration. Now that we've gone public there are a lot more eyes on us, and several people wanting to help. How do we organize them and keep them engaged?

There are a few things we should nail down right away:

• Is this forum to be the hub for discussion? Should we make it public now?
  • If so, should we also rename it if possible?
    • In that case, what are we calling this project?
  • Do we also (yet) need a place for more real-time coversation? Discord?
• How are we tracking who's doing what? Are GitHub issues + projects sufficient?
  • As other programmers join, where do they start? Do we have/need a backlog of tasks yet?

Once the above are settled, I think we'll be ready to start inviting more people to start working on things.

Also a quick tip in case you didn't know: I found you can "watch" an entire forum to get notified whenever new threads are started. Just click "Watch Forum" at the upper right of the forum page. Never miss a topic again!

 

[WildWeazel]

Personally, I think it makes sense to go ahead and open this forum. That was always a possibility so AFAIK there's nothing here that shouldn't made public, and the older threads might help provide context for newcomers. I would like to pick a better name now that we know what we're doing, but it doesn't necessarily have to be the TBD name of the game.

I have not worked much with GitHub's projects, but they look like any other Kanban-style board. Keeping all technical artifacts in one place seems to make the most sense for now, and developers are likely to at least be familiar with GitHub.

 

[Quintillus]

Is this forum to be the hub for discussion?

I don't see any reason for it not to be. Discussion seems to be working well here, and we're all at CFC anyways.

I'll also note that it is making a huge difference that there have been three of us making technical progress. It's so cool, and motivating, to see other parts of the code getting improved, and features starting to come together, as I work on an area. Then there will be forum updates, too. That positive feedback loop hadn't been achieved in the late winter time frame.

Should we make it public now?

I'm actually not so sure about that quite yet. In one sense, I'd like to wait until we have something with a little more meat on the bones before throwing the doors wide open on all the inner workings. Competing points:

- We should open it up to additional people who want to help. E.g. KingArthur mentioned he may be able to offer some technical support, and at some point we'll need to start getting art assets together; Kyriakos mentioned an interest in that.
- A lot of what we have is very much in progress, preliminary, and technical. I'm reminded of when I visit the Caveman2Cosmos forum in Civ4 C&C. It's pretty much hopeless for me as a non-dev (on that project) to follow the dev updates, and the dev updates are most of the forum, so it can be hard to figure out what the recent updates are. So, the volume of technical updates we have might drown out the things that the average Civ3 forum user is interested in, even the average Civ3 forum user who is interested in the project.

So I'm not sure if making the whole forum public would actually make it any easier for the consumer part of the intended audience to follow. Perhaps that means I'm favoring an approach of being liberal with invites to forum regulars?

Should we rename it if possible, and if so to what?

Barring any brilliant ideas, or brilliant absurd codenames, I think it's a little early for settling on a "final" name. C7 seems to be catching on a bit (although I have yet to remember what it stands for, too many C's), but will it be the forever name? Old World was Ten Crowns for long enough that the program is called Ten Crowns internally to this day; according to Solver, they realized at some point in the development that Ten Crowns was no longer a name that made sense. We might have something similar happen.

For the forum, Civ3 Future Development? We could rename it to C7 Development. I suppose that adds a bit of intrigue - "What's C7?" - to the newcomer. But it's subject to the same possible renaming later concern.

Overall, this is a "I don't see a compelling reason, but don't feel strongly about it either" question for me.

Do we also (yet) need a place for more real-time coversation? Discord?

I don't think we do yet. Flintlock, Puppeteer, and I have been posting on the forums pretty consistently after making updates. I'm also kind of not a fan of Discord since it tends to swallow up documentation when information is posted there, and it gradually falls farther and farther back in time. XenForo tends to be better for organization and finding things later on. I'd almost favor just having an IRC chat room where you can post things in real time, but it's all ephemeral so there's not a temptation to put knowledge that should stick around in that discussion space. #fiftychat seems to be available as a temporary option; their status indicates that they've migrated to Discord.

How are we tracking who's doing what? Are GitHub issues + projects sufficient?

Currently, forum posts and reading what others have been posting about. That isn't really scalable, but on a team of three it has worked well, or at least it appears to be from my vantage point. Puppeteer and Flintlock have been working on the map, so I've stayed away from the map and focused on other shiny things. So far they seem to have avoided stepping on each others' toes, as far as I can tell.

I suspect GitHub issues are sufficient, at least for now. But basically anything as long as you can figure out what others are working on, without them having to be online.

As other programmers join, where do they start? Do we have/need a backlog of tasks yet?

So far, the method has been "find a shiny thing that looks interesting, and work on it". And at this phase, there is no shortage of shiny things to work on, many of them being ones that are needed early on. Though I've tried to keep an eye on the overall goal, which was a motivation for the milepost threads, and also part of why I started looking at data/mechanics yesterday. The latter was necessary, but hadn't shined bright enough to receive attention until then.

At some point, we likely will need a backlog of tasks, but at this point, once you get over the "eating an elephant" factor with picking up Godot, it's hard to step anywhere without finding something to add. Then again, I'm saying that as someone who is no longer elephant-overwhelmed, as I was in February and until I got the main menu somewhat sorted this week. So I guess I'm saying we could select a few things, but it might also work to just say, "fire up C7 and suggest a few things that look interesting for you to work on, we'll let you know if anyone's already working on them".

------------------------

My question that is kind of along the same vein, at least in terms of wider communications:

What do we want our plan to be for dev diaries/binary releases?

For dev diaries, I think it's a great idea, and even if we open the forum to everyone, we should still have them so those who want a higher-level view can have it (can you imagine if Paradox had their dev forum open, but no dev diaries? Keeping up with Victoria III would be a nightmare). I don't know what the frequency should be, however. This is also complicated by the fact that I expect our pace to be highly variable. We may have made more progress in a week than in the six months before that, and while hopefully it won't be quite that erratic over the long term, it will likely be quite inconsistent.

For binaries, I know one of the tasks is getting CI set up to build those automatically. But while having a binary on every commit makes it available, it doesn't tell someone interested in taking it for a whirl if there's anything new (or enough new to be noticeable) since they last did. Maybe linking up binaries from dev diaries would make sense?

I'm also wondering when we first want to make binaries available. That can be before the CI task is set up; they're easy to build. But we may want to have a launcher of some sort, if for no other reason than setting the Civ3Home in a user-friendly way, for Linux/Mac. Puppeteer also mentioned that the Mac version runs into untrusted/unsigned developer issues. So, it may make sense to release by platform as we iron out issues. Windows could be released five minutes from now, for those who have Civ3 installed; Linux could be ready to go once we add a launcher for setting Civ3Home and get a chmod +x reliably integrated; Mac might take longer.

 

[Puppeteer]

I think I agree with Quintillus on about everything, including any ambiguities.

I'm personally fine with working in the open, but I'm really not sure how much the casual reader will get out of it. I personally "think out loud" a lot which is my form of informal documentation, but it tends to confuse...almost everyone else as I can quickly segue my thoughts between topics.

I know the project needs formal structure and direction, but it is definitely the "chasing shiny things" and (positive) engagement feedback loop that gets me or keeps me going. If it starts feeling like a job with task assignments I'll probably get demotivated quickly. I'm more about my own chaotic journey than focused on a gold release.

Yet I also understand that some tasks do need to get done for all this to have any worth to the wider world, so there's a balance in there somewhere between sporadic bouts of manic fun coding interspersed with weeks or months of disengagement, and making progress that others can at least can fire up on their own machine.


Speaking of less fun tasks, I guess I should try to get an auto build pipeline ready for at least Windows.

As far as OS releases, for the foreseeable future C7 is going to be heavily dependent on a Conquests/Complete file hierarchy handy. Which pretty much rules out casual Linux (if there is such a thing) and Mac users. If they had or have enough motivation and ability to copy a file tree over to their non-Windows platform, at this stage of C7 I think it's reasonable to expect them to jump through an extra hoop or two to make C7 work.

Not saying setting env vars is sustainable; I just mean setting permissions or explicitly enabling an executable to run probably aren't showstoppers for them. The env var thing is a holdover from a very pre-alpha personal project that's still there because this went from idea to able to make pretty pictures relatively quickly.

 

[Puppeteer]

I'm wondering if there is a way to involve some of the would-be artist helpers sooner rather than later. That might mean having a preliminary native graphics format, or perhaps we'll end up with several graphics format options in the end. Like Freeciv.

It's not necessarily the optimal design for a AAA game company, but for a project like this, it might allow earlier engagement and lessons learned if we have a progression like legacy graphics only -> rudimentary original graphics -> the final form, ideally with the ability to choose one or even mix and match.

I actually have an alternate idea about using legacy graphics in a new way that might mesh well with new ways...but I digress.

On a perhaps related subject, I think at some point–and probably sooner rather than later–we should be able to fire up C7 with Civ3 nowhere in sight and have it not crash and have at least a 1990s Geocities-looking splash screen. (Ok, not Geocities, but at least a color field with some text on it.) Maybe I can adapt my SVG map graphics from an earlier version of Civ3SAT so they could even generate a map.

Spoiler Cheesy but openly licensed map graphics :

Edit: I am also looking for an excuse to introduce Lua to C7. Certainly anything we release now would drastically change in API over a short period of time, but I'd like for script-inclined people to do something. Heck, they might even accidentally program some lasting game mechanic logic for the project.

 

[Puppeteer]

Oh, one more thing. About opening the forum up: I think it's safe for most, but I recall being vaguely concerned about something @Ozymandias posted. May have been a personal email or a phone number.

There might have been an email or two posted while discussing contacting other folks who might be of assistance, but I'm not aware that any of them might be problematic (unless they contained contact info...maybe that's what I was thinking of).


I don't really see a need to use comms outside of CivFanatics, but I'm starting to think there are basically two distinct Civ3 communities: This one, and the Discord where SuedeCivIII hangs out which I imagine is more composed of users who discovered Civ3 via Steam in recent years whereas this forum is mostly ... tenured Civ3 players and modders. It's possible we're missing out on would-be contributors that hang out there and not here. Or maybe there's more overlap than I think.

 

[Puppeteer]

Another thought: We may need a mod/bic-analog definition sooner rather than later. Graphics formats, index files, folder structure, zip or not...

If people want to contribute media, we'll have to give them a recipe how.

We also need to figure out how to handle it. Oh, that's packaging and distribution, or largely me. I'm quite sure we don't want it git. Ok, this one is probably my thing, and I'm thinking it needs to involve zipped folders and/or PCK archives. And some structured document with a mod API versioning.

 

[Quintillus]

I know the project needs formal structure and direction, but it is definitely the "chasing shiny things" and (positive) engagement feedback loop that gets me or keeps me going. If it starts feeling like a job with task assignments I'll probably get demotivated quickly. I'm more about my own chaotic journey than focused on a gold release.

I think this is very important, especially early on. I am sure there are some people who are good with boring task assignments on open source projects (or maybe they just find things fun that most other people don't find fun?), but I think part of the reason we didn't get moving in the late winter/spring was we tried to put too much structure around it. After WildWeazel's posts in late October, three of us just kind of dove back in after shiny things, and we're making progress.

I've also noticed with my editor that the things that are interesting tend to get done. Next are things that may not be quite as interesting, but are important for getting things working together well. Last are things that are good ideas but not exciting and not end user impacting. So, for example, implementing Spaceship Parts was in the second category because it's not modded much. But when I looked at "what's left that you can do in the Firaxis editor but not mine?", I realized I'd never done it, so that provided the motivation to finish it.

I suspect that for now, chaotic good is the way to go. As we progress, we can move towards neutral good and lawful good methods.

Speaking of less fun tasks, I guess I should try to get an auto build pipeline ready for at least Windows.

I put this in the "if someone enjoys this, great, but if not, no rush" category, due to how easy it is to do manually. I'm reminded of when I was on a six-week assignment at work, initially planned as four weeks, for the whole project, no code to finished deliverable. Our company policy was that you always set up a build pipeline right away, because it tended to provide a lot of return on investment over time. But we realized that over the course of our project, we wouldn't gain the time back from the pipeline that we would spend manually compiling it and sending the compiled artifact where it needed to go. I'm thinking that for now, we're in a similar place. If it's demotivating to work on the build pipeline, there's no point in doing it, because we can create a build for each OS in 2 minutes or less apiece.

Once we start noticing some pain from doing it manually (or not having it done for us automatically so it can catch failed builds), would be when we should do it. It also helps that our team is small for now; the work team I mentioned was also small, at 4 developers plus a project manager and a UI artist.

I agree with your thoughts re: motivation on Linux at the present time, with the caveat that I'm not that Civ3 Linux user myself.

 

[Quintillus]

Replying to the other posts together, and sporadically.

I'm wondering if there is a way to involve some of the would-be artist helpers sooner rather than later. That might mean having a preliminary native graphics format, or perhaps we'll end up with several graphics format options in the end. Like Freeciv.

I think it would be a good idea to involve artists sooner rather than later, although I don't know whether it needs to be immediate. But they will likely have more informed opinions on what makes sense for a new format (I don't know whether PNG with alpha built in, or SVG, or a combo of both depending on the situation, makes the most sense, or something else entirely, for example).

I do agree that we should make it not crash if it can't find the graphics. Although come to think of it, doesn't Civ3 crash if it can't find some graphics? It just has a pretty good shot of making it to the main menu first.

I do recall that Discord now that you mentioned it, and it's a good point that it probably is the largest off-CFC audience of active Civ3 users these days.

 

[Puppeteer]

I put this in the "if someone enjoys this, great, but if not, no rush" category, due to how easy it is to do manually.

Ok, good. I'm kind of thinking I'll just set it up to build on my home server...which is currently sitting in storage. But I'll have an apartment Friday and will get my towers in there not too long after.

I'll ensure the pipeline and process is documented in a repo on the C7 org, and I want to proof it working in the cloud, but I'll have plenty of home-based compute online 24/7 so might as well do some automated work there.

Side notes for some of my silly ideas: It would be fun to see if I could build on a Raspberry Pi. And for no good reason at all I'm wondering if I could have a 24/7 long http poll set up from my home server to my cloud server to instantly catch any messaging for GitHub commits.

Although come to think of it, doesn't Civ3 crash if it can't find some graphics?

True, but I already told people we weren't going to port CTDs from Civ3. I was actually wondering earlier today about C# exception handling, and I think it's bubble-up handling, so I was wondering if we could/should put a try/catch as far up as we can to catch all unhandled exceptions.

And as I'm typing this I realize it's name must be TotallyNotACrashToDesktopException.

Edit: Oh, I mixed ideas there. It's still funny (to me), but I actually want to handle would-be CTDs, not rename them. Maybe a handler function could be named that.

 

[Puppeteer]

Re: art formats. Yeah, I guess we should ask them at some point. Godot seems to natively support PNG, JPEG, and WebP. But we can probably support a lot more with ImageSharp. (Oh, I don't guess that's currently in the project, but in test apps I've used it to export my FLC and PCX readers to other formats successfully.)

I've been imagining 32-bit RGBA images, but multilayered so there is a civ color layer/mask and a smoke mask. I guess at some point I should do a rudimentary proof of making a multilayer (and maybe multiframe for animated?) image file then having Godot compost it and display it. Because my layers-for-smoke-and-civ-color ideas are going to require additional processing.

Ideas popping into my head: I may not need smoke layers as the base image has variable transparency. And instead of a civ color mask layer, maybe we could have a fake "palette" coded into the top-left pixel or even a dedicated data row...or something where it gives a range of alpha values that are assigned to civ colors. Or maybe just one special prearranged alpha value and use the luminance of those colors as a gradient as a guide to civ color luminance.

And oh yeah, there are two civ colors in Civ3.

Anyway, I guess there are a few things to iron out: how to implement shadow, smoke, and civ color, how that works with graphics formats, and what artists' tools will easily export.


I was a bit surprised and disappointed that SVG isn't supported by Godot, but after thinking about it, it makes sense. A 2d vector format doesn't really work well with a 2D raster engine. Maybe if the SVG were externally converted to a flat 3D mesh it could be used in that format, but that doesn't seem like I road I want to tread down anytime soon.

Bummer. I like SVG's git-ability and scalability. And I was going to actually use my svg-based stuff from my older c3sat maps as a stand-in for C7 art, but if I do I'll have to convert them to raster formats first. Oddly, ImageSharp doesn't handle them, either. I guess vector and raster graphics don't mix well.

 

[Puppeteer]

Oh. I just realized most graphic assets should be Node2Ds. Of course there would be a set of provided scenes that would require only a bundle of image and config files, but more advanced users could make their own scenes in Godot using anything they can concoct in Godot

And that means I should refactor the legacy Civ3 assets as such.

Edit: Security concerns for running 3rd-party scenes, though. The script has full access to everything. I'm wondering if we can load a scene, detach any scripts, and then attach it to the node tree. Hmm, but that still has a code run point at the constructor. I'm not the first one to have this concern; there are open issues on people wanting sandboxed mod ability. Maybe there is a way to load the type and see if it has an overloaded constructor? Or pre-vet the file as raw data before loading?

 

[WildWeazel]

I'm fine with waiting a bit longer before opening the forum. There's not a lot here yet for the average would-be player, and we can do a quick scan for sensitive info while there aren't many threads to go over.

I think this is very important, especially early on. I am sure there are some people who are good with boring task assignments on open source projects (or maybe they just find things fun that most other people don't find fun?), but I think part of the reason we didn't get moving in the late winter/spring was we tried to put too much structure around it. After WildWeazel's posts in late October, three of us just kind of dove back in after shiny things, and we're making progress.

I suspect that for now, chaotic good is the way to go. As we progress, we can move towards neutral good and lawful good methods.

Fair enough! You guys are doing great and I certainly don't want to take the wind out of your sails. I'm a very top-down, big-picture thinker so I do kind of enjoy decomposing work and fitting it into a larger plan, but I completely understand most people on a passion project just wanting to write fun code. In fact, if y'all want to keep hacking cool stuff together and let me come along behind and refactor it into something more structured, that's fine by me. We will need some degree of feature tracking soon enough, but a simple kanban board of WIP should suffice. As long as we're making progress I won't prescribe more than the bare necessities to keep track of features.

That said...

Ok, good. I'm kind of thinking I'll just set it up to build on my home server...which is currently sitting in storage. But I'll have an apartment Friday and will get my towers in there not too long after.

I'll ensure the pipeline and process is documented in a repo on the C7 org, and I want to proof it working in the cloud, but I'll have plenty of home-based compute online 24/7 so might as well do some automated work there.

Side notes for some of my silly ideas: It would be fun to see if I could build on a Raspberry Pi. And for no good reason at all I'm wondering if I could have a 24/7 long http poll set up from my home server to my cloud server to instantly catch any messaging for GitHub commits.

I would really like to see some automation infrastructure sooner rather than later, though. I also have a RPi to throw at it, but do we really need hardware or can it be done with free cloud services now that we're on a public repo?

True, but I already told people we weren't going to port CTDs from Civ3. I was actually wondering earlier today about C# exception handling, and I think it's bubble-up handling, so I was wondering if we could/should put a try/catch as far up as we can to catch all unhandled exceptions.

And as I'm typing this I realize it's name must be TotallyNotACrashToDesktopException.

Edit: Oh, I mixed ideas there. It's still funny (to me), but I actually want to handle would-be CTDs, not rename them. Maybe a handler function could be named that.

Making it gracefully handle missing files instead of crashing is some low hanging fruit that could really drive home how we can make this a better Civ experience for the less technical users. Their eyes might glaze over at talk of scripting and human readable files and flexible graphic formats, but not crashing when you misspell an icon name is something everyone can appreciate.

 

[Quintillus]

Great point about low hanging fruit with avoiding crashes.

I also have a spare Raspberry Pi. We could all have a home server/Pi building the code! I guess the point I'll add is it'll be nice to have something visible to everyone. If it's only visible locally on one of our Pis or servers, and then that person decides to go traveling for a month like I was doing this fall and isn't seeing if the build succeeds, and no one else can either, that's not great.

The larger plan structure has certainly been helpful and I think is part of the reason we've been able to make progress. I know I've referenced it quite a bit. Feature tracking does sound like a good idea, and at this point I could easily put, e.g. that I was working on making Unit Action Buttons only appear when appropriate for the unit. It could also help avoid stepping on each others' toes as we approach the intersection of UI controls and unit graphics/animation.

 

[Puppeteer]

Heh, I just yesterday looked into whether or not Godot works on rPi and wondered if it could be a build platform. (Answer: *Maybe* on both, but only with GLES2, and we'd have to compile Mono support in ourselves. So probably not a high priority. And *maybe* only the rPi4? Not sure on that last one.)

Yeah, if there is a free cloud build service, I'll kick the tires on that. I tend to think enterprise-y and didn't want to steer the project into fee-based compute. You've seen me switch my Civ3-related projects from Python to C# briefly, then back to Python, to Go, some side work on JavaScript, and now back to C# again. I'm kind of the same about infrastructure, so I won't mind prototyping builds on multiple CI/CD pipelines...it's kinda my thing and good experience to keep current.

I do have an interest in doing it, so I think it will be not too long after moving in. But if you have the drive and want to implement it, you're not taking my candy away.


Heh...Quintillus talking about rPi, too. Ok, now you've done it! Here I go: I *have* thought more about rPi than I should, and I have four in the car right now. (I've been traveling 2.5 months, going from hotel to hotel with with me, a cat, and whatever else fits in my car, and I have a ridiculous amount of portable compute for one person and one cat.)

Since a distributable is just a from-Godot redistributable binary with the project folder packaged up and the Mono compiled to DLL assemblies, I suspect an rPi could compile the Mono assemblies, make the package, and provide a deliverable without even needing to run Godot itself. *Especially* if it's a dev non-release build where we're not terribly concerned about any tidying up in the package that Godot may or may not do.

Ok, I'm stopping myself there. I could babble on about having standalone nonrelease builds, how to get them, and if they are even meaningfully necessary in the case of Godot, and speculating on how new graphics are packaged and handled, but I really need to test some of that out before spouting off about it too much..)

 

[WildWeazel]

I played around a bit with GitHub's new features in our org page and discovered Discussions: https://github.com/orgs/C7-Game/teams/devs/discussions/1
There's this new concept of a Team, which seems to be a sub-organization that people have to be assigned to, which is where the Discussions live. Those are basically a mini-forum that we may want to use for concrete technical stuff since it's colocated with the repo. I made some notes there about Projects, which are the other feature of interest. We had one on the Prototype repo that was just a kanban board, but now they have a more advanced beta version too. I'm not sure why Teams are distinct from Organizations, or why Discussions are only available in a Team, but that's how it works.

 

[Quintillus]

I'm not sure why Teams are distinct from Organizations, or why Discussions are only available in a Team, but that's how it works.

I do know why teams are distinct from organizations! At one of the Organizations I worked for recently, everyone got added to the company's GitHub Organization. Some things were available to everyone in the Organization.

But it was a consulting company, and while for some clients the work would be done on the client's source code control system, for others (more likely for projects where we did all the work, rather than a combined consulting/client team), the projects would be hosted on our company's GitHub Organization. It would not have been appropriate for everyone at our company to have access to those client-specific repos, however. Rather than control access on an individual basis, we'd create GitHub Teams, and add or remove people to teams, and set the access based on Team membership.

I don't see a need to have multiple Teams for our project at this point in time.

 

[Quintillus]

For some reason I can't find the post where @WildWeazel mentioned kanban boards, or at least linked to them. But there were two:

https://github.com/C7-Game/Prototype/projects/1

and

https://github.com/orgs/C7-Game/projects/2/views/1

and a third one that I found:

https://github.com/orgs/C7-Game/projects/1

Which one do we want to use? I was going to toss my Disband/Popup work on one of them. I don't really have strong feelings on which one we go with, but we don't want to find out we're all adding our progress to different ones. We also should probably delete the ones we aren't using so we don't do that accidentally.

(Even in the chaotic phase, I think this would be an improvement relative to adding TODO all over the code for capturing things we realize we need to do, but which we punt on now in favor of other shorter-term things. I've found the general concept quite helpful for my editor after realizing around 2014 that it was tough to remember all the cool feature ideas and bug reports if they fell off the most recent or second-most-recent page on the forum)

 

[WildWeazel]

That first one is the original. The others are new and old style respectively at the org level. Seems like the middle one gives us the most options to work with- new features, and can span multiple repos. I vote for that one, after seeing that you can still view it in kanban mode.

I suggest writing up anything that can be worked on soon as a note in Todo, which can be converted to an issue later as needed. Assign yourself and move columns as you start working.

 

[WildWeazel]

Good news, I recruited 2 more developers to join us!

@Skywhisperer is a strategy gamer and professional C# developer!

@TowelCiv3 is a multiplayer league player and a programmer on Mac!

Welcome both! There's a lot to take in here but not a lot of direction yet. We're still figuring out our process and next steps. If you see something that needs done, call it out and/or do it. The "milestone" threads are where most feature discussion is happening.