i used to spend a shitton of time working on ioQuake3 and Tremulous. btw, the first version of the multi-protocol functionality (for Amsterdam Unlimited; only covering 2 protocols, and having a couple of quirks) took 3 days, each consisting of 18 hours of work.
1 Like
Some people have more fun developping/modding than playing the games themselves.
2 Likes
@DevHC brought up some concerns on the TODO that I share:
Specifically, details on what they pretain exactly. What are they? What do they do? How do they benefit Tremulous? Is the X amount of work required to finish them really worth the Y amount time it would push back the 1.3 release?
this is better phrased as being in the server component, ie. is server-side, but is not in the gamelogic module.
the first and most important thing is to design a karma system, to try to find out whether such a system is possible without it being counter-productive.
or just say why the feature should be included. or, if the case is obvious, then simply request the feature.
additionally, if not just saying why, then one could use a better file (patch) transmission medium than this forum.
- TODO: get files.grangerhub.org to work again, and as a file-paste repository.
- TODO: set up a grangerhub.org pastebin.
- TODO: implement a productive issue reporting system.
constructive, u mean ?
I moved a bunch of posts to best keep the discussions on this thread on-topic and still have the conversation make sense. To keep this topic productive, I ask that all further posts in this thread be about which items should stay, should be removed, or should be added to the list, as well as about the status of the items on the list.
For me it reads like this:
Red: nothing because it includes NOTHING DONE or WE PLAN BUT WE HAVE NOTHING SO⌠yes nothing.
Orange: NOTHING or MOST because we can call 1% or 0.01% a progress and 99% aswell so what does this tell me? NOTHING.
Green: SOMETHING works or its NEARLY DONE means: 50% ? 80%? 99% ? Another NOTHING to me because GREEN LIGHT means to me = lets go, ready! but here it means: maybe or hmmmm
So if you assign this to Tremulous 1.3 it simply means: NOTHING IS DONE because its either NEARLY DONE or ITS NOT DONE. What a fuckup!? I donât say that you didnât accomplish something but how hard is it do design a common sense based âto do listâ?
How about this: red: 0%, orange >50%, green 100%
The reason we are calling green working prototype or near complete is because as we continue to develop new bugs related to those items may be discovered, or we may find that some fine adjustments may be required in those items from continued tests. We wouldnât say that any of those items are absolutely completed until the initial release.
But when all the items on the list are green (and we may decide to remove a bunch of the items on this TODO for the initial relase and move them to the TODO of a subsequent release) we will be having the initial release shortly after, and any further bugs or needs for fine adjustments that might be discovered for those items at that point would be addressed in subsequent releases.
So in other words, if an item is green, that particular item no longer stands in the way of the initial release, so in that respect it does mean âlets go, ready!â
Every red item on the list has already been planned/designed, and we do know how to approach the work on those items, but we arenât counting the planning as part of the progress, we are only counting tangible progress like coding and asset production.
Regarding having something more definitive on the rest of the color scheme many of the items require different amounts of work. Some items on the list single features/enhancements, other items are whole new systems. Additionally we canât anticipate potential tricky bugs or other unexpected hurdles related to development that may be encountered. So it is very difficult to quantify the progress for each item on the list via a general scheme.
The best we can do is indicate that we begun working on a particular item, and then indicate if that item has gotten to a state where we would be satisfied with that particular item if the initial release happened at that moment.
Actually there are a couple of the orange items on the list now that we will be changing to green probably in the next week that may not require any more coding, but I want to see how well they work out in a couple of more dev games before changing their status.
Makes sense but on the other hand its a nasty way to cover the projectâs real progress state.
That has nothing to do with saying: its done or not. You can say a bug is solved or not or at least ballpark the amount of work left or done and if you donât know then its simply not done. Also that is the savest way to be honest and genuine.
Like saying âwe work on itâ. 
Why is it so bad if you use an honest indication system about your progress?
You know, thats the statements that make me angry again. Wishy washy statements, repeated again and again.
Once more: if you change it to green then what does it tell me? Orange means: not done, green means: not done.
You say it MAY require more coding in the future: not done!? Can you reproduce my confusion?
Iâm talking about bugs that emerge as we develop an âorangeâ item, we canât say before hand how much work it would take to fix bugs we donât yet know about. Additionally often times many aspects of an enhancement/feature/system may require trial & error before getting it right.
What I mean by it being green is that when we have the initial release, and nothing changed with that item, we would be satisfied with its inclusion in the initial release. But I canât say that it is âabsolutely doneâ in the sense that there will definitely not be any changes to it before the initial release (such as further fine tuning from dev game observations, or fixing some later discovered bugs related to the item).
Even when we have the initial release, we canât say that the project nor any part of the project is completely done, as we intend to continue to work on Trem after the initial release and have more subsequent releases. Additionally we hope that more independent developers will continue to mod trem. So we canât use the term done, we can only state if an item is good enough for a release.
Orange means that progress started but it isnât ready enough for the initial release.
Green means it is ready enough for the initial release.
This indication system is honest, it just has some fuzzy aspects. If we assign a percentage of the progress of an item chances are it would either be overestimated, or underestimated, which either way sends an inaccurate indication of the actual progress of the project. The most honest way I see we can indicate the progress of these items is to just say for which items work has begun, and which items are ready enough for the initial release.
Additionally, the public can observe the results of the progress for many of the items firsthand on the test7341 server, on the website, and (when we get to that point) with the public tests of the updater & pre-release client.
We also started a page that has an rss feed with our private repo that shows the title, date, and author of commits. Although that page can use some improvement (cough, cough, @romdos , cough, hint, cough), like the ability to scroll back a couple of hundred commits, have a prominent link on the main website and in these forums, and show a few more key branches like âdevelopâ, âswirl-vanilla-commonâ, and âvanilla-devâ.
The main thing is that we have a public definitive list of the items that we are requiring for the initial release, so that it can be understood that when all of these items are ready individually for the initial release, we will be ready to have the initial release.
Nothing is absolutely done but SOMETHING can be done for 1.3. ANYTHING after that would be 1.x or 1.3.x whatever. This is common. The way you use ur todo list is still confusing and covering the real state of your project. If you still want to keep this then add another color for: DONE FOR 1.3!. At least then i see what is done and what isnt because the other colors doesnt tell me jack shit as i wrote some posts before. I think this is logical and i donât think there are any good reasons not to do this.
Then change the description from
to
i propose detailed colors:
- [color=violet]proposed[/color]
- [color=red]accepted, but not yet started[/color]
- [color=yellow]begun planning or prototyping[/color]
- [color=orange]planned out, or its prototype salvagable[/color]
- [color=brown]begun implementing[/color]
- [color=green]implemented (by a basic programmer)[/color]
- [color=cyan]implemented by a generally error-free programmer, or implemented and well-tested[/color]
- [color=blue]frozen (in some stage to be identified somehow)[/color]
- [color=grey]scrapped (after some stage to be identified[/color]
3 Likes
(DevHC Approved!)1
1 NOT
1 Like
I propose one more:
#[color=#665404]SOONâ˘[/color]
1 Like
OFFTOPIC: blizz is probably joking but there are people who legitimately think this. i donât understand this mentality. tremulous is open source and at the end of the day, the community just wants the best possible tremulous successor. iâd say we should be grateful that there are multiple interest groups willing to resurrect this shitty quake 3 mod from life support.
3 Likes
@dGr8LookinSparky @Matth maybe we need to have some rough estimates of difficulty or developer points for each item and percent done or hours left kind of remark next to them.
@Matth weâre not full time devs here so itâs really difficult to estimate how long something is going to take because it depens on irl availability of ppl.
2 Likes
You seem to be giving the impression that reorginization of the TODO⢠is necessary. I disagree. Reorganizing assumes the developers are spending their [time + effort + energy] inefficiently. For example: Improving code < writing up a PDF instruction manual. I doubt this is the case based on what Iâve read from this thread.
The inadequacy of organization isnât the issue, it is clearly the inadequacy of resources (people, free time, effort).
tl;dr Stop talking shit, start doing shit. Kids are busy with school. Just get shit done. That is basically what everyone (including the detractors) actually cares about.
The above sentence is a general statement, not a direct one to cengique.
3 Likes
The primary purpose of a public TODO is to better inform the general public of the status and progress of the project, especially since there are significant parts of the code not yet released. While we might be working efficiently on the development under the circumstances and with the available resources, that doesnât mean that the communication of the projectâs status and progress canât be improved upon.
3 Likes