[x3d-public] procedure for timely resolution of straightforward X3D specification issues

[Michalis Kamburelis]

Thanks everyone for answering. Nice ideas (I still use classic encoding
daily!), good news about spec comments being in Mantis. Leonard’s documents
are great, reading them right now:)

I thought about the “open GitHub” thing for a while. I want to emphasize
that I’m extremely grateful to all the people that helped make X3D the
standard it is today. Despite some issues, it’s still the *best* format for
3D data we have today, and it is open —- this is a great achievement. And I
benefit from this fact on a daily basis, when developing my engine and
games around X3D.

At the same time, I want X3D to be more used by other people/software. The
fact that ugly unspecified proprietary formats like FBX gain ground, and
have sometimes better support in 3D authoring/rendering software than X3D…
well, it’s troubling.

With this introduction done, let me try to make some constructive comments:)

   1.

   I understand that the need to keep some things closed is necessary for
   some members, for some issues.

   At the same time, this is some barrier for the public contributions.

   Compare this with open-source software development —- if you *really*
   want to welcome the community input, you need to make your development
   public. This means making a *current*, bleeding-edge, version of your
   software available for testing. And this means opening a reliable channel
   to submit bugs/changes to your stuff.

   That’s why GitHub is so popular. Because it’s technology (GIT, pull
   requests) promotes community contributions. (It’s not only GitHub/GIT, of
   course. You can more-or-less say this about any open-source software hub
   and version control system.)

   Opening the membership to individual professionals, for a moderate
   price, is a great thing… but it’s not the perfect world. Again compare it
   with open-source software development —- if every potential contributor
   would have to go through a “member” process before even *seeing* the
   development version of the software… well, you would just have a lot less
   contributors.
   2.

   So, one idea how you could “have a cake and eat it too”:)

   GIT and GitHub allow you to reliably merge changes, 2-ways, between your
   repositories. So maybe:
   -

      Make a public repo “X3D spec in progress (without any
      potentially-secret stuff)” on GitHub.
      -

      And keep secret (member-only) the “X3D spec in progress (*with*
      potentially secret stuff)”. When something “secret” is ready to be made
      public (after all, it’s a necessary step toward being part of
the final X3D
      spec), then merge it from “secret” to “public” repo.
      -

      And the big advantage: the public contributions could be applied
      directly to the public repo. The public would have a “current
spec version,
      as much as we can show”, to comment on and improve, in an open-source
      fashion (real issue tracker, pull requests and so on).
      3.

   I know that many standards have been developed like X3D, or in much more
   restricted fashion. As I said, welcoming input from individual
   professionals, and offering them membership for a moderate price (it’s 100
   USD per year, as far as I see) is a visible and very appreciated gesture.

   But, maybe we can make it better? I found two examples of standards
   (close to my heart and open 3D) that have specifications openly available
   in GitHub, by Khronos:
   - Vulkan : https://github.com/KhronosGroup/Vulkan-Docs
      - glTF : https://github.com/KhronosGroup/glTF

   I don’t know are these the “latest” spec versions of Vulkan/glTF,
   possibly development on new spec features happens partially elsewhere. But
   I know I can fork these specs on GitHub, submit issues (bugs) there, submit
   pull requests (correction that can be easily applied).

   This is a great feeling, and I would love X3D to be such open.

Thanks for reading:) Best regards,
Michalis
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160225/48cd7e0f/attachment.html>