MrAnonGuy wrote:My only point in the OP was to suggest that it's understandable to want your baby to be perfect, but perhaps a bit unrealistic.
Just to drag this thread back on topic, my original post was about clearly defining what tasks are left for 1.0, and coming up with a strategy for actually getting it done. This was never a discussion about "perfecting" the project.
Yes, but my point was simply that it's not uncommon for the desire for perfection to get in the way of achieving a more realistic milestone, and when plotting the roadmap to that milestone, it can be beneficial to be mindful of that.
From the perspective of some anon guy on the internet, I'm wondering how the roadmap will be determined and who has the final say? At some point, someone, perhaps the leader of this project, whoever that is, needs to step up and provide a list of project specifications. When those specs are met, V1.0 will be release. It will be the final list and it will not change, unless there is a very persuasive argument made to change it.
raevol wrote:So I'd like to formulate a plan for tackling this. My strategy would be this:
1. Establish standards for documentation (I think DestinedToDie [edit: I meant DavidD] and psi29a may have started/finished this?)
2. Do a call for help on our documentation.
3. Once our documentation is at a good spot, identify and prioritize our remaining "big ticket" development tasks
4. Do a call for help for development
My personal view is that if we sit on our hands and wait for another scrawl to bless us with an inordinate amount of work, the project is going to stagnate and die off. I'd really like the team's support on this, so that we can coordinate PR and onboarding for documentation contributors. Thoughts?
I'm sorry to be a bit of a jerk, but it's almost like you didn't read the rest of the thread. Can we keep this on topic please?
No problem. I thought the topic was a "Round Table" discussion, and that I was making valid points and suggestions. Guess that's not the case and I'm somehow "Off Topic".
@MrAnonGuy, I'm sorry to have gotten in a huff and been a jerk. I am trying to move this discussion forward though, and we've already discussed several times the issue of delaying 1.0 for inconsequential bugs, and even in this thread we have discussed how to prioritize which "features" or "requirements" we need to satisfy to be able to release 1.0. That doesn't excuse me being a jerk though. My apologies!
I'm somewhat worried about the suggestion to make filling in bug reports easier. I think it would be nice to have an easier way of filling out the report, but unless it's carefully designed, we may just end up with a lot of pointless complaints lacking enough information for devs to actually find the source of the problem. I find that bad or incomplete data collection can be even worse than none at all. Perhaps a feature we should include in our list for 1.0 is automatic bug reporting that sends basic data about their setup such as modlist and settings and computer hardware.
Also, I like where all this is going, but I'm a bit confused as to the lists everyone is making. Hasn't our goal always been to reach feature parity with Morrowind for our 1.0 release? I actually agree with most of the lists, but I just want to make sure we all don't fall into the trap of feature creep. I think any features beyond that should only be included if there is a great reason to do so, based on specific criteria. For example, if we decide our main criteria for a 1.0 release is to increase users and attract more developers, then only features which support that should be included. Based on this you can justify including shadows and distant land because people are so used to playing with MGE that without those features users will probably ignore the fact that OpenMW runs far more smoothly than any modified version of Morrowind. Otherwise I think development needs to be focused just on the features left on the bugtracker timeline, then enter the official beta phase where we can clear up some more bugs, then a 1.0 release.
I'm a little worried that all the craziness I have caused lately has derailed any momentum that may have been made towards formulating a plan to actually get to our 1.0 release. Again:
raevol wrote:My strategy would be this:
1. Establish standards for documentation (I think DestinedToDie [edit: I meant DavidD] and psi29a may have started/finished this?)
2. Do a call for help on our documentation.
3. Once our documentation is at a good spot, identify and prioritize our remaining "big ticket" development tasks
4. Do a call for help for development
My personal view is that if we sit on our hands and wait for another scrawl to bless us with an inordinate amount of work, the project is going to stagnate and die off. I'd really like the team's support on this, so that we can coordinate PR and onboarding for documentation contributors. Thoughts?
Do people agree that making a push towards getting more development support, and by preceding that with a push on documentation would be a good idea? Anyone have any counter arguments to this? The argument I was met with before was "the man hours needed to add new developers to the project would far outweigh the benefit gained, given that scrawl is already single-handedly catapulting us towards 1.0". But now that scrawl has had to take a much-deserved step back, the project is somewhat stalled. Onboarding new developers at this point *is* going to take a lot of man hours, but we can streamline a lot of that by pouring effort into documentation beforehand.
raevol wrote:
1. Establish standards for documentation (I think DestinedToDie [edit: I meant DavidD] and psi29a may have started/finished this?)
2. Do a call for help on our documentation.
3. Once our documentation is at a good spot, identify and prioritize our remaining "big ticket" development tasks
4. Do a call for help for development
[...]
By "documentation" you mean "documentation of our source code", i.e viewtopic.php?f=6&t=3644, right? I have often heard new developers say that they needed some time to find their way in our code, so this could be an option. The question is: who would be willing to do this? @DavidD, have you made any progress on this? What is your opinion on raevol's proposal?
Apart from that, it seems absolutely necessary to recruit new developers, at least on OpenMW's side. -- I doubt that people are willing to dig through hundreds of lines of code only to solve a minor bug though. Can we apply certain stimuli to increase their motivation? (Maybe move some post-1.0 features to v1.0?)
Atahualpa wrote:By "documentation" you mean "documentation of our source code", i.e viewtopic.php?f=6&t=3644, right?
No, we mean both. Documentation is a broad term that covers everything from user manuals, to tutorials to source documentation. My project was to unify this around sphinx and readthedocs.com: https://readthedocs.org/projects/openmw/
This was successful, and DavidD has made a merge request already. There is still more work to do, but we need people that want to write "documentation".
So people wishing to write "documentation" regardless of type, can do so by forking openmw on github and writing it, then submitting it for inclusion which triggers our peer review from the developers and those interested in documentation. Once merged, RTD renders the latest from master.
All documentation is in the ReST format, and thanks to sphinx/RTD we can have the output rendered as anything we want: html, LaTex, pdf...
