MyBB Community Forums

Full Version: Moving Forward: State of MyBB
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Before I start: I don't really care what The Team decides is best for MyBB, but this is my take on it. I have no intentions of leaving this community because I don't get my way; but--

-- I have been pondering the best way to move forward.

As someone who develops their own platform I have about as much influence here as a damp, dead, squid. Awesome for Calamari, but in terms of usefulness, very little. There are reasons I don't submit PRs, and they're unlikely to change, this is not a solution for me.

Instead, I am going to make suggestions about internal policy, and how you guys manage the development process - because there's no illusion; things have trouble getting done around here. One has to look at the commits to 2.0 to see that.

Therefore, my suggestion is threefold:
  • Feature Lock 1.8; work solely on security fixes, and that image bug. It is stable enough at this point where it works well enough to soldier on short-to-mid term.
  • Get cracking on 2.0; because at the rate we are going, we're never getting 2.0. When it was announced, it was spectacular. Now people are leaving because they don't expect to see it in the next year or two, if ever.
  • Develop KPIs for the team as a whole to work towards. Where do you want to be in 1, 2, 3, 6, 12, 18, 24 months time?

- Feature Lock:
I say to feature lock MyBB 1.8 because, realistically, it doesn't need new features at this point. It is stable enough now to last as long as is necessary. Security fixes are a necessary evil; but the bugs that remain are not going to make or break the experience. Yeah, sure, if they start to cause issues, fix them; but don't use "1.8 is broken and needs to be fixed" as an excuse for leaving 2.0 alone.

- Get cracking on 2.0:
I imagine this one is rather self-explanatory. Not going to explain it, but leads into:

- KPIs:
Clearly, MyBB needs a similar approach to the one I have; even if it's my friends ripping on me for not getting things done. By developing KPIs for the team to work towards, you're setting milestones you want to reach by a particular date, and not meeting them - whilst not necessarily a deal breaker - should be seen as a negative.

I am not suggesting creating deadlines for things based on full-time work - I get that this is a volunteer project; I know all too well how that feels - but you have got to be accountable to the larger community for a product that you are providing, rather than the current method of "Well, it's open source, submit a PR". A lot of the webmasters I know, know nothing about design and HTML/CSS, let alone PHP, let alone Object Oriented, let alone however MyBB is coded. They don't want to submit PRs, they want a modern software that works.

I really don't believe that a 1.10 is the best way forward as it will simply create a 1.8 situation. "It's just a stopgap". 1.8 is the stopgap. Like it or lump it.

So, suggested KPIs - no necessity to be bound by them, but for the sake of the argument:

- 1 month:
Release of new MyBB 1.8 version; with the fix for that image issue that shows the timestamp.

- 2 months:
Initial development on 1.8; aim to have at least one element completed. User Authentication/Registration would be an ideal starting point.

- 3 months:
MyBB 2.0 at a point where a development update can be posted, providing an insight into a system that is, actually, being programmed, and is, actually, making progress.

- 6 months:
Alpha for 2.0. Not quite ready for a beta release; but should be able to be previewed in the same way XenForo 2.0 was before being installed on the base forum for them.

- 12 months:
MyBB 2.0 Beta 1. Long shot here, but I imagine that this would be relatively easy to achieve.

- 18 months:
Preperation for the release of 2.0, given that there should have been at least 4 beta releases between Beta 1 and now, working towards gold.

- 24 months:
MyBB 2.0 gold. Move the site over to it, announce 1.8 EOL.

Accountability leads to results. Go ahead, pick it apart.
Very well said, but I feel people are still really excited about the 2.0. The problem is that users are moving to different forum software's because of active development and lucrative default features that are offered by some forum software.
Once people switch a forum software, it is difficult to bring them back. (This is my view)
Apart from the deadlines that's our current strategy of putting 1.x into maintenance mode, meaning that:
  • security-related fixes and improvements will continue to appear,
  • compatibility fixes will continue to be applied (1.8 is compatible with most recent versions of the stack software, and 1.8.13 will fix known issues with PHP 7.2 that should reach GA this year),
  • high-priority issues will continue to be addressed,
  • random PRs for other issues will continue to be merged in,
  • some changes to how packages are built and released that are planned for 2.0 will also make their way to 1.8 since they're compatible.

We have been looking into how the 1.x series can take advantage of 2.0 code (reusing certain modules for areas that need fixing in 1.8 anyway) and to what degree we can refactor it, which could solve some problems (major 1.x improvements aside - reducing the structural gap between 1.x and 2.x or putting some 2.0 modules in to see how they perform and to have them reach stability faster).

The current pace of work depends on personal circumstances given the reduced number of contributors, so it's hard to establish deadlines for 1.8.x releases or 2.0 milestones.
(2017-10-02, 10:42 AM)WallBB Wrote: [ -> ]Very well said, but I feel people are still really excited about the 2.0.

Thank you - I don't doubt that people are excited for 2.0, but there needs to be a substantial movement on it for any number of reasons; including but not limited to community faith.

(2017-10-02, 10:42 AM)WallBB Wrote: [ -> ]The problem is that users are moving to different forum software's because of active development and lucrative default features that are offered by some forum software.
Once people switch a forum software, it is difficult to bring them back. (This is my view)

A lot of people are moving to XenForo; at one stage it was because it was hip; now - because of the state of development on the elsewheres of the internet; and that - sadly - includes here.

(2017-10-02, 12:29 PM)Devilshakerz Wrote: [ -> ]Apart from the deadlines that's our current strategy of putting 1.x into maintenance mode, meaning that:
  • security-related fixes and improvements will continue to appear,
  • compatibility fixes will continue to be applied (1.8 is compatible with most recent versions of the stack software, and 1.8.13 will fix known issues with PHP 7.2 that should reach GA this year),
  • high-priority issues will continue to be addressed,
  • random PRs for other issues will continue to be merged in,
  • some changes to how packages are built and released that are planned for 2.0 will also make their way to 1.8 since they're compatible.

This is good news. I stated in my original post that the deadlines and KPIs that I had put in were for the sake of the argument; you're welcome to create your own - but realistically, you need deadlines and you need to meet them. It's all well and good to write blog posts saying you're going to release every three months, but unless you follow through and/or are liable to the community, there's no point.

(2017-10-02, 12:29 PM)Devilshakerz Wrote: [ -> ]We have been looking into how the 1.x series can take advantage of 2.0 code (reusing certain modules for areas that need fixing in 1.8 anyway) and to what degree we can refactor it, which could solve some problems (major 1.x improvements aside - reducing the structural gap between 1.x and 2.x or putting some 2.0 modules in to see how they perform and to have them reach stability faster).

I feel this is unwise as it involves more screwing about with the 1.x series that - after 2.0 - really won't matter anymore. I don't see many people running phpBB2 and expecting support/updates/improvements. Same thing applies here.

I really feel that the best way forward is to get actual man-hours into 2.0. The sooner it's released, the sooner the existing clusterf- of what's currently ongoing is gone.

(2017-10-02, 12:29 PM)Devilshakerz Wrote: [ -> ]The current pace of work depends on personal circumstances given the reduced number of contributors, so it's hard to establish deadlines for 1.8.x releases or 2.0 milestones.

Yes, I know - as I said in my original post - and I completely appreciate it. I can give you the shovel to dig out, but I can't make you.
we have some different ideas flowing around internally on some stuff.
(2017-10-04, 06:42 AM)andrewjs18 Wrote: [ -> ]we have some different ideas flowing around internally on some stuff.

Why are these different ideas flowing around internally, instead of publicly?
(2017-10-04, 03:17 PM)Eric J. Wrote: [ -> ]
(2017-10-04, 06:42 AM)andrewjs18 Wrote: [ -> ]we have some different ideas flowing around internally on some stuff.

Why are these different ideas flowing around internally, instead of publicly?
Also would like to know......
There is not much point in publishing some half-baked ideas that might not be feasible. We first need to evaluate the advantages and disadvantages and work out a solid concept. Also it's important to add detailed explanations to make sure all of our users are able to understand what we are talking about.
(2017-10-04, 03:17 PM)Eric J. Wrote: [ -> ]
(2017-10-04, 06:42 AM)andrewjs18 Wrote: [ -> ]we have some different ideas flowing around internally on some stuff.

Why are these different ideas flowing around internally, instead of publicly?

Just to expand further on Stefan's comment, we have plans to disclose and publish what we've been talking about, but first we wanted to make sure that what we were discussing was even possible with the current resources on hand. We don't want to get people's hopes up on something that could very well be impossible to achieve. The original post in question even includes the fact that the thread will be posted publicly before too long.
(2017-10-04, 04:25 PM)StefanT Wrote: [ -> ]There is not much point in publishing some half-baked ideas that might not be feasible. We first need to evaluate the advantages and disadvantages and work out a solid concept. Also it's important to add detailed explanations to make sure all of our users are able to understand what we are talking about.
just the opposite IMHO.... its open project, so community is allowed to take part in shaping product (in this case MyBB)..... Having this in mind, all development-related things should be discussed in public.
Pages: 1 2