1. Document major status of project on monoxna.org
I think the homepage should make it clear the general status of
monoxna. Ie, pre-alpha, and it can't run most XNA applications at
this point. This will weed out potential users from potential
developers.
2. Support & IRC
I don't think IRC should be listed as the main point of support, since
it does not have much activity. I think a mailing list is more
appropriate at this stage.
Are the forums really worthwhile at this stage? There is such low
traffic with the project right now, it might be best to funnel it all
to one place. (Ie, the mailing list.)
3. Document how to submit changes
4. Move to github for code hosting
This will enable potential developers to easily fork and send
pull/merge requests.
There is a natural home for this project under the mono organization at
https://github.com/mono/monoxna
5. Document the relationship to MonoGame
I don't quite understand this ... Why should I contribute to monoxna
vs. MonoGame?
Thanks for your time,
-Jordan
I agree. That is why we started this page
http://code.google.com/p/monoxna/wiki/Status a while back. It could
use some work though.
>
> 2. Support & IRC
>
> I don't think IRC should be listed as the main point of support, since
> it does not have much activity. I think a mailing list is more
> appropriate at this stage.
I've opened up the mailing list so that everyone can join again.
>
> Are the forums really worthwhile at this stage? There is such low
> traffic with the project right now, it might be best to funnel it all
> to one place. (Ie, the mailing list.)
The home page at this point is no where near the stage that I would
like it to be, so I have been thinking of removing the link from the
google code page for a while. I really like the idea of having a
dedicated homepage in principle, but that would require the manpower
to manage the site.
>
> 3. Document how to submit changes
This should obviously be part of this page
http://code.google.com/p/monoxna/wiki/Helping. I'll try to add it
before bed tonight.
>
> 4. Move to github for code hosting
>
> This will enable potential developers to easily fork and send
> pull/merge requests.
>
> There is a natural home for this project under the mono organization at
> https://github.com/mono/monoxna
The monoxna project has moved in the past as well, so I would prefer
it if we could stay on google code for now. I'll look into the whole
github thing myself to see if I think the benefits are to great to
pass up.
>
> 5. Document the relationship to MonoGame
>
> I don't quite understand this ... Why should I contribute to monoxna
> vs. MonoGame?
Actually the MonoGame was news to me, but it looks like it's a rename
of the XnaTouch project? If that's the case, they've taken a slightly
different approach than the idea behind MonoXNA. Like Mono we aspire
to be binary compatible with the .NET equivalent (XNA). I don't think
that's the case with MonoGame though. They just provide the same API.
If I'm not mistaken they based the first version heavily on our
codebase, with the underlying API's changed. They certainly have a
bigger community than MonoXNA, so the best argument I can make for
joining MonoXNA instead is the underlying philosophy of providing a
cross platform alternative, that in addition to being binary
compatible, provides an equivalent development environment.
>
> Thanks for your time,
>
> -Jordan
>
> --
> You received this message because you are subscribed to the Google Groups "MonoXNA" group.
> To post to this group, send email to mon...@googlegroups.com.
> To unsubscribe from this group, send email to monoxna+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/monoxna?hl=en.
>
>
-lavima
If you aligned with the mono project, then you are unlikely to change
again soon. I don't think the entire mono project would take change
source control systems / hosting providers lightly.
How git/github would benefit a potential contributor (such as myself):
* Let me publish changes for the main tree without the hassles of patches, etc.
How it would benefit the tree maintainer (ie, you):
* You don't have to concern yourself with giving out svn access
* It is easier to deal with changes from people without svn access
* Authorship stays intact for contributors w/o svn access
One other thing. I'm not sure if you use monodevelop, but the next
release will have git support built in.
Thanks,
-Jordan