Free Allegiance Forums

Pretty sure it was perfectly clear in both Quantus and Allegiance meeting posts that it's on IRC. Several of us are without mics.

Really need to get people with mics. IRC is horribly inefficient for something like this, let alone the fact that miscommunications are almost guaranteed. I don't think $5 is a very difficult commitment for something that would pay off every Sunday anyway

TB

You also have to factor in the "People talking over each other" bit.. I think IRC may actually be better because then there is also a transcript.

IRC has logs. A huge advantage in my book. It's also very easy to miss something on ts, or forget something. With IRC, there are no such problems.

For those that were not present at last nights meeting, here are the notes that I took. Some may not be fans of the massive bullet point list, but it was being written while I talked in channel. It also gives me actionable items for the future

Dev team activity levels need to improve.
Beta builds must be produced more frequently.
Advertising for testing must be more public, community participation required.Must set more reasonable goals for milestones.
Sidethought: release current build to public if testing is complete & no new input?DevZL/Fascilitator/"Person that pushes things" needs to be active. Active recruitment for the dev team, increase member count.
Add sticky to main dev forum for application information.One time public post (General/News forums) for current members.ASGS message if we want absolutely everyone seeing it.Dev environment must be conducive to active development.
Bug tracking/documentation needs to improve.
Move to official adoption of Trac.
Get Imago/Fuzz' work, apply it to FAO Trac.
Remember bug from Trac, fix it on FAO as well (AutoQuery mod)Move away from Code Bugs & Suggestions
Lock forum from new topics, set to readonly. Public post instructing public on how to notify dev team of a bug/suggestion. Include method for starting a thread on FAO for broad discussion, move to Trac when confirmed by Devs (minimize spam on Trac).Clean up forums, make process easy & clear for public.Add method for tracking a tester's stats.
Record information such as Processor, Video Card, etc.Viewable for devs, to find potential testers for specific problems. (e.g. A crash bug specific to ATI cards)Possible locations: FAO forum profile (not ideal), forum post (cental location, better), Trac (same), open to other suggestions.Review process for beta testing.
Find out best process for releasing new builds to the public.
Talk with Orion/Madpeople regarding new method of pushing EXEs, if no current (& efficient) method exists.Ensure that things are thoroughly tested, no more premature releases.
Dev alpha tests on localhost, beta tests with community.Encourage active participation (x2, I know. Need this otherwise testing doesn't happen)Requests for more open forums.
Imago wants dev team access to Server Operators forum.Orion wants Developer's Lounge to be open to all (fully open or read only can be figured out later).Use current Dev Lead's Office for any sensitive threads (e.g. exploitable bugs).New Zone Leader/AZLs.
Cort has offered his resignation.Discussed who decides on new ZL (current ZLs).Fascilitator (gets people the tools they need) vs Leader (actively instructs/runs team)"Slow is gay" -- ImagoHow CSS will influence development process.
Provide crash logs/stack traces from production builds to developers. (.log files in

HOLY @#(!.

Eh.. I don't see anything in that list about just completely getting rid of the idea of a "Dev Team", but I guess people didn't like that idea

Essentially, I think that there shouldn't a membership requirement to contribute to Allegiance. I know anyone can send .patch files to the dev ZL (who doesnt exist), theoretically.. but it seems kind of dumb to do it that way.

IMO, we should just encourage "Allegiance Development", with 1 or 2 official FAO lead developers who set the agenda and decide what development efforts will make it into an FAO release. Everyone else is a contributor, who has access to the FAO development forum. This is, afterall, an open (shared) source game, but we certainly haven't organized things like it is.

I have no idea if this idea is feasible, it just seems to me that it's something worth thinking about, because the status quo is not working, and nothing I see in TB's post seems drastic enough to get things really moving.

TheBored wrote:QUOTE (TheBored @ Mar 23 2010, 12:10 AM) Move away from Code Bugs & Suggestions
Lock forum from new topics, set to readonly.

Can I suggest changing it to only "Suggestions", that way we stop trac being spammed by noobs with "supposing we could fly miners...", also lets us use the software designed for discussions to discuss/hash out the details of the request like in this thread before submitting it to trac - don't want devs implementing the first version of the idea only for someone else to not line it and change it half way through.

QUOTE Record information such as Processor, Video Card, etc.Viewable for devs, to find potential testers for specific problems. (e.g. A crash bug specific to ATI cards)Possible locations: FAO forum profile (not ideal), forum post (cental location, better), Trac (same), open to other suggestions.[/quote]
CSS functionality request: Record system information and upload to central server, probably should be user initiated to avoid spyware accusations.

QUOTE Find out best process for releasing new builds to the public.Talk with Orion/Madpeople regarding new method of pushing EXEs, if no current (& efficient) method exists.[/quote]
Will comment later, but it boils down to it being hard to get stuff on the AU/asgs update if a few people are away, and the asgs update mechanism requiring that files be locked to update them when they don't need to be locked.

madpeople wrote:QUOTE (madpeople @ Mar 23 2010, 04:39 AM) Can I suggest changing it to only "Suggestions", that way we stop trac being spammed by noobs with "supposing we could fly miners...", also lets us use the software designed for discussions to discuss/hash out the details of the request like in this thread before submitting it to trac - don't want devs implementing the first version of the idea only for someone else to not line it and change it half way through.

That's pretty much what this part of the forum would be for.

madpeople wrote:QUOTE (madpeople @ Mar 23 2010, 04:39 AM) CSS functionality request: Record system information and upload to central server, probably should be user initiated to avoid spyware accusations.

Right, it would easily be built into the [now ASGS] user database. We can implement that and choose where to put it later. A default box could be checked to "Send diagnostic report to developers" which they could uncheck on install.

madpeople wrote:QUOTE (madpeople @ Mar 23 2010, 04:39 AM) Will comment later, but it boils down to it being hard to get stuff on the AU/asgs update if a few people are away, and the asgs update mechanism requiring that files be locked to update them when they don't need to be locked.

apt-get update && apt-get upgrade

Some good stuff in there. Especially the bits about Beta testing. Will have a thorough read through later.