roadmap.rst 3.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475
  1. Roadmap
  2. #######
  3. What direction is the project going? What exciting new features are coming soon?
  4. We do not publish detailed roadmaps, but it’s possible to get a sense for our general direction
  5. by utilizing the following resources:
  6. * Our `feedback and planning group`_ is used to host early discussion about what will be worked on next.
  7. * Our `Github milestones`_ represent a general direction for the future releases of Elgg.
  8. This is the closest thing to a traditional roadmap that we have.
  9. * `Github pull requests`_ will give you a good idea of what’s currently being developed,
  10. but nothing is sure until the PR is actually checked in.
  11. * We use the `developer blog`_ to post announcements of features that have recently been checked in to our development branch,
  12. which gives the surest indication of what features will be available in the next release.
  13. .. _feedback and planning group: http://community.elgg.org/groups/profile/211069/feedback-and-planning
  14. .. _Github milestones: https://github.com/Elgg/Elgg/issues/milestones
  15. .. _Github pull requests: https://github.com/elgg/elgg/pulls
  16. .. _developer blog: https://community.elgg.org/blog/all
  17. Values
  18. ======
  19. We have several overarching goals/values that affect the direction of Elgg.
  20. Enhancements generally must promote these values in order to be accepted.
  21. Accessibility
  22. -------------
  23. Elgg-based sites should be usable by anyone anywhere. That means we'll always strive to make Elgg:
  24. * Device-agnostic -- mobile, tablet, desktop, etc. friendly
  25. * Language-agnostic -- i18n, RTL, etc.
  26. * Capability-agnostic -- touch, keyboard, screen-reader friendly
  27. Testability
  28. -----------
  29. We want to **make manual testing unnecessary** for core developers, plugin authors, and site administrators
  30. by promoting and enabling fast, automated testing at every level of the Elgg stack.
  31. We think APIs are broken if they require plugin authors to write untestable code.
  32. We know there are a lot of violations of this principle in core currently and are working to fix it.
  33. We look forward to a world where the core developers do not need to do any manual testing to verify the correctness of code contributed to Elgg.
  34. Similarly, we envision a world where site administrators can upgrade and install new plugins with confidence that everything works well together.
  35. TODO: other goals/values?
  36. FAQ
  37. ===
  38. When will feature X be implemented?
  39. -----------------------------------
  40. We cannot promise when features will get implemented because
  41. new features are checked into Elgg only when someone is motivated enough
  42. to implement the feature and submit a pull request.
  43. The best we can do is tell you to look out for what features
  44. existing developers have expressed interest in working on.
  45. The best way to ensure a feature gets implemented is to discuss it with the core team and implement it yourself.
  46. See our :doc:`/contribute/index` guide if you're interested. We love new contributors!
  47. Do not rely on future enhancements if you're on the fence as to whether to use Elgg.
  48. Evaluate it given the current feature set.
  49. Upcoming features will almost certainly not materialize within your timeline.
  50. When is version X.Y.Z going to be released?
  51. -------------------------------------------
  52. The next version will be released when the core team feels it's ready and has time to cut the release.
  53. http://github.com/Elgg/Elgg/issues/milestones will give you some rough ideas of timeline.