Next SMF Discussion
September 20, 2011, 04:49:08 PM Posted by Norv on September 20, 2011, 04:49:08 PM in Next SMF Discussion | 28 CommentsThere hasn't been a blog post from developers for a while, unfortunately, and I'll take the opportunity of a little initiative we've started, to present a few things to you. Yes, these are only a few things.
We all know how long the development cycle of SMF 2.0 has been, until it has reached the stable version, and during a significant part of this time, it has been feature-locked. Many proposals for new features or improvements made during this time simply couldn't be considered for inclusion in SMF (2.0). That, however, has changed now. The next SMF (what we call 2.1, and 3.0) is open for discussion, and to your thoughts and proposals.
For this purpose, we have created a new board, Next SMF Discussion, where SMF team will present to you various ideas, proposals, considered for 2.1, mods for 2.0 considered for inclusion in 2.1 core, official themes we're planning to make available to the community, plans for officials mods for next versions (2.1/2.x/3.0), and so on.
It is easy to see that during all that time, proposals and requests have practically kept "piling up", if I may say so, and there are many little enhancements (and a few significant enhancements) that have proven appropriate, for SMF to grow and move forward. SMF developers have already a good idea of a number of things we want to make real, for SMF to be inline with the landscape of the web today, and bring much more added value to you all, but there is more to it. SMF development itself has become very closed (IMHO) through the years, and that is not suitable for an Open Source project, nor fair, nor beneficial for our users nor the project. There are many reasons that have contributed to it into which I won't get here (it would become an endless post!), however let me say this clearly: this must change, and it was and is my goal to change it, since the moment I've taken charge of it.
While it won't happen over night, we have already taken steps towards it. The release of SMF 2.0 with an Open Source license, a permissive license, BSD (three-clause), is only one of them. To open development of the next SMF to the community, we are now taking this little other step: we are starting to present to you the features and enhancements we're considering for the next SMF version, and invite you all to take part to the discussions on them, offer us your feedback, alternatives, insight into how they may affect you, whether you like or want them or find them useful - or not -, for SMF developers to know better how your needs are served by the software.
The topics proposed for your attention will be here:
Next SMF Discussion
This "list" we're starting to post for community feedback is a list compiled by the SMF team, from many sources, among which:
If you're interested as admin of your forum, in a feature, let us know, in Feature Requests and Next SMF Discussion.
If you're interested, as coder or designer, to take part to contributing code for something cool you want to build, you can do so, by a mod for 2.0 you can propose for official distribution for 2.0 and integration in 2.1, by a theme you want to propose for official theme of 2.0 or next theme of 2.1, by a patch to 2.0 code or modifications made to your own SMF variant, whichever suits you. For example, Akyhne has stepped up to create a version of Classic theme for 2.0, that we're making available to the community as official theme of 2.0. (as additional download, not in the main package, but developed and supported officially).
We are working on making it easier than this actually, for them coders and designers from the community to contribute to SMF, for which purpose we have created last year the Consulting Developer role, and I'll come back on that and others. (I'm really trying to keep this short! ... really.)
------
The SMF team has a few amazing people who stepped up to help the developers with the difficult and insanely time-consuming task to do the initial gathering of Mantis features, endless internal forum posts, approved requests from the community boards, etc, and will present them for your feedback, step by step, by topics they'll open in the Next SMF Discussion board. (that's because they're amazing, but don't tell them I said so!). There are more than a hundred proposals, and of course not all will be for one version (no, we won't take four years, and no, SMF will not become bundled with everything either!). In fact, there are also official tools and mods and themes proposals and contributions among them, as you will see, not only core software alone. I'm keeping an eye on them all and sort them out as we move forward, along with their developers. For example, you may see mods developers, who have been working on mods we intend to make official mods of SMF 2.0, and integrate in 2.1, opening their work for your feedback on 2.1 inclusion of their mod.
In parallel with this initiative, we were working with TBG developers to convert what we have in Mantis to it, set up TBG as tracker for the SMF project (Mantis is terrible on a few aspects), integrate it with the community forum and theme. Once that is done, I'll take those that stay accepted for the next SMF versions, and track them there for everyone to be able to follow easily, along with their development status. What we really need are better development tools, open to the community, for easy management of the SMF software, but those are coming too.
Please note:
As the work on getting these ideas for 2.1/3.0 out in the community progresses, topic by topic, your feedback, your opinion, your alternative proposals or experience with your forum, are essential to the choices we are going to make! So please, help us know what you're thinking, and help us build the software YOU find useful. The developers of SMF are not building this for ourselves alone, but for you to use, build on, extend, customize, adapt easily, as you see fit. We're moving forward with making SMF a true open source project, one driven by the needs of its community, and open to everyone to take part to. And you can quote me on this one.
Of course there is much more to it, but hey. I said I'll keep this, umm, short...
We all know how long the development cycle of SMF 2.0 has been, until it has reached the stable version, and during a significant part of this time, it has been feature-locked. Many proposals for new features or improvements made during this time simply couldn't be considered for inclusion in SMF (2.0). That, however, has changed now. The next SMF (what we call 2.1, and 3.0) is open for discussion, and to your thoughts and proposals.
For this purpose, we have created a new board, Next SMF Discussion, where SMF team will present to you various ideas, proposals, considered for 2.1, mods for 2.0 considered for inclusion in 2.1 core, official themes we're planning to make available to the community, plans for officials mods for next versions (2.1/2.x/3.0), and so on.
It is easy to see that during all that time, proposals and requests have practically kept "piling up", if I may say so, and there are many little enhancements (and a few significant enhancements) that have proven appropriate, for SMF to grow and move forward. SMF developers have already a good idea of a number of things we want to make real, for SMF to be inline with the landscape of the web today, and bring much more added value to you all, but there is more to it. SMF development itself has become very closed (IMHO) through the years, and that is not suitable for an Open Source project, nor fair, nor beneficial for our users nor the project. There are many reasons that have contributed to it into which I won't get here (it would become an endless post!), however let me say this clearly: this must change, and it was and is my goal to change it, since the moment I've taken charge of it.
While it won't happen over night, we have already taken steps towards it. The release of SMF 2.0 with an Open Source license, a permissive license, BSD (three-clause), is only one of them. To open development of the next SMF to the community, we are now taking this little other step: we are starting to present to you the features and enhancements we're considering for the next SMF version, and invite you all to take part to the discussions on them, offer us your feedback, alternatives, insight into how they may affect you, whether you like or want them or find them useful - or not -, for SMF developers to know better how your needs are served by the software.
The topics proposed for your attention will be here:
Next SMF Discussion
This "list" we're starting to post for community feedback is a list compiled by the SMF team, from many sources, among which:
- your requests, as you let us know in Feature Requests board, over time. There are many things, small or not so small, that SMF could do to better to be more useful, and while of course they're not meant for next version alone, we're addressing the most requested and useful, in core or in official mods.
- support requests, and the deficiencies in the software they're pointing at. Mods developed for 2.0 to address them, that we are considering for inclusion in SMF 2.1.
- the experience of our international communities users and admins, the difficulties faced by our translators working with SMF files in their current format (yes, it's time to refactor EmailTemplates! - before GravuTrad burns me alive, he's mean like that)
- difficulties faced by modders and themers, their needs for SMF to be more customizable, the success that a few enhancements have already had (like the hooks we have changed and added in SMF 2.0 last RCs)
- coding support requests, the most frequent requests more likely show us how SMF is used and what is more useful to address (or what additional tools would be handy for you to have at your disposal)
- difficulties faced by developers of big mods, or their feeedback on how maintainable is the code, whether it is easily extensible or not, and how to make it more understandable, and better documented. (yes, we're switching to a standard documentation for SMF code, easier to read and easy to parse by existing tools for offline documentation)
If you're interested as admin of your forum, in a feature, let us know, in Feature Requests and Next SMF Discussion.
If you're interested, as coder or designer, to take part to contributing code for something cool you want to build, you can do so, by a mod for 2.0 you can propose for official distribution for 2.0 and integration in 2.1, by a theme you want to propose for official theme of 2.0 or next theme of 2.1, by a patch to 2.0 code or modifications made to your own SMF variant, whichever suits you. For example, Akyhne has stepped up to create a version of Classic theme for 2.0, that we're making available to the community as official theme of 2.0. (as additional download, not in the main package, but developed and supported officially).
We are working on making it easier than this actually, for them coders and designers from the community to contribute to SMF, for which purpose we have created last year the Consulting Developer role, and I'll come back on that and others. (I'm really trying to keep this short! ... really.)
------
The SMF team has a few amazing people who stepped up to help the developers with the difficult and insanely time-consuming task to do the initial gathering of Mantis features, endless internal forum posts, approved requests from the community boards, etc, and will present them for your feedback, step by step, by topics they'll open in the Next SMF Discussion board. (that's because they're amazing, but don't tell them I said so!). There are more than a hundred proposals, and of course not all will be for one version (no, we won't take four years, and no, SMF will not become bundled with everything either!). In fact, there are also official tools and mods and themes proposals and contributions among them, as you will see, not only core software alone. I'm keeping an eye on them all and sort them out as we move forward, along with their developers. For example, you may see mods developers, who have been working on mods we intend to make official mods of SMF 2.0, and integrate in 2.1, opening their work for your feedback on 2.1 inclusion of their mod.
In parallel with this initiative, we were working with TBG developers to convert what we have in Mantis to it, set up TBG as tracker for the SMF project (Mantis is terrible on a few aspects), integrate it with the community forum and theme. Once that is done, I'll take those that stay accepted for the next SMF versions, and track them there for everyone to be able to follow easily, along with their development status. What we really need are better development tools, open to the community, for easy management of the SMF software, but those are coming too.
Please note:
As the work on getting these ideas for 2.1/3.0 out in the community progresses, topic by topic, your feedback, your opinion, your alternative proposals or experience with your forum, are essential to the choices we are going to make! So please, help us know what you're thinking, and help us build the software YOU find useful. The developers of SMF are not building this for ourselves alone, but for you to use, build on, extend, customize, adapt easily, as you see fit. We're moving forward with making SMF a true open source project, one driven by the needs of its community, and open to everyone to take part to. And you can quote me on this one.
Of course there is much more to it, but hey. I said I'll keep this, umm, short...
Comments
Hot Stuff, Norv! This is heady business you're talking about.
Inclusive discussions... Woot!
With the changes that are happening in Yuku-land and other free, hosted forums out there, this is a great time to consider ways to welcome the more advanced admins among them to take the giant step to self-destiny by moving to a forum software that is reasonably adaptable for newcomers to the self-hosted, self-designed, and self-maintained forum world.
Let me take some time to reread and absorb more of what you've said, and I'll be back to offer my thoughts.
Thanks and Cheers to all the SMF Team~!
Inclusive discussions... Woot!
With the changes that are happening in Yuku-land and other free, hosted forums out there, this is a great time to consider ways to welcome the more advanced admins among them to take the giant step to self-destiny by moving to a forum software that is reasonably adaptable for newcomers to the self-hosted, self-designed, and self-maintained forum world.
Let me take some time to reread and absorb more of what you've said, and I'll be back to offer my thoughts.
Thanks and Cheers to all the SMF Team~!
Wow, Norv! What a mouthful!
It will be exciting to see new versions coming out routinely, with small bundles of features and other refinements.
Maybe future versions will also DROP things we don't need any more!
It will be exciting to see new versions coming out routinely, with small bundles of features and other refinements.
Maybe future versions will also DROP things we don't need any more!
I believe SMF must go on way to socialize. Better friendship and follow system. Like and Dislike and rating tools for posts and members and ...
I really liked the idea of getting community involved. I'll try my best to suggest some features in there.
. Seriously, after a long long time I've read a post completely. Nice one, Norv.
Quote from: AngelinaBelle on September 20, 2011, 08:35:57 PMA big +1 to that. For sure some features can be dropped.
Maybe future versions will also DROP things we don't need any more!
Quote from: Norv on September 20, 2011, 04:49:08 PMLiar
I said I'll keep this, umm, short...
. Seriously, after a long long time I've read a post completely. Nice one, Norv.It's a great step forward 
Good work team
Good work teamVery good vision norv!
This is some good managment!
I only hope you will have with this more developers propositions to integrate smf dev team. Lots of ideas and ear them is good, but materialize them is another thing...
And no i won't burn you alive norv, i will just torture you by inches
(crazy file isn't it lol)
This is some good managment!
I only hope you will have with this more developers propositions to integrate smf dev team. Lots of ideas and ear them is good, but materialize them is another thing...
And no i won't burn you alive norv, i will just torture you by inches
(crazy file isn't it lol)In the Norvz0r I trust.
I actually liked "Saguaro" 
But it's a great step moving forward and I can't wait to see the 2.1 theme!
But it's a great step moving forward and I can't wait to see the 2.1 theme! Hooray! 
Hi there!
Good words!
Let us see if there will also be good works!
Good words!
Let us see if there will also be good works!
This is very interesting, I'll be on the news, thank you very much 
Regards enik...
Regards enik...
Well Norv ... Great plan ... but how long is the time to see a final 2.1 or a 3.0?
For the 2.0 the team needs more then 4 years ... and I think the "one man show" need longer to 3.0 ...
As long as the development team is not changed significantly, and increased with experienced programmers, rather drift a meteor the earth, as it will give an SMF 3.0 ...
For the 2.0 the team needs more then 4 years ... and I think the "one man show" need longer to 3.0 ...
As long as the development team is not changed significantly, and increased with experienced programmers, rather drift a meteor the earth, as it will give an SMF 3.0 ...
we hope that the release is 2.1 will take less time then 2.0 did but we will not put a strict deadline on it.
What about "clode" as code name? Our "cloud"?
Quote from: feline on September 23, 2011, 12:48:32 PM
Well Norv ... Great plan ... but how long is the time to see a final 2.1 or a 3.0?
For the 2.0 the team needs more then 4 years ... and I think the "one man show" need longer to 3.0 ...
As long as the development team is not changed significantly, and increased with experienced programmers, rather drift a meteor the earth, as it will give an SMF 3.0 ...
Development of 3.0 is not a one man team, don't worry about that. The people you see in the development team on SMF are not the only people working on 3.0
Quote from: Fustrate on September 23, 2011, 05:08:43 PMQuote from: feline on September 23, 2011, 12:48:32 PM
Well Norv ... Great plan ... but how long is the time to see a final 2.1 or a 3.0?
For the 2.0 the team needs more then 4 years ... and I think the "one man show" need longer to 3.0 ...
As long as the development team is not changed significantly, and increased with experienced programmers, rather drift a meteor the earth, as it will give an SMF 3.0 ...
Development of 3.0 is not a one man team, don't worry about that. The people you see in the development team on SMF are not the only people working on 3.0
Exactly.
Quote from: AngelinaBelle on September 20, 2011, 08:35:57 PMHell yeah. That would be awesome.
It will be exciting to see new versions coming out routinely, with small bundles of features and other refinements.
Maybe future versions will also DROP things we don't need any more!
Hopefully with everything now in place (or so it seems) we'll see more frequent updates, and not have to wait like 5(?) years for a new release x)
Can't wait to see how this goes
Just noting that as of last night Australian time, our trunk is now running jQuery as the official default javascript library.
This gives us a lot of scope for improvements in functionality and accessibility with a minimum of extra code.
The list of what will be included is not set in stone at the moment, but we will be tending towards things we regard as truly useful rather than just frills for the sake of frills.
At the moment only the drop menu system has been done, but more things will follow. To quote from the team's dev board:
We wont be backporting this menu system to the 2.0.x branch, but I think I'll write up a mod and/or tutorial for adding them.
This gives us a lot of scope for improvements in functionality and accessibility with a minimum of extra code.
The list of what will be included is not set in stone at the moment, but we will be tending towards things we regard as truly useful rather than just frills for the sake of frills.
At the moment only the drop menu system has been done, but more things will follow. To quote from the team's dev board:
Quote from: Antechinus on October 20, 2011, 05:47:52 AM
Update (for anyone who give a rat's): These menus now work with the latest jQuery.
After doing a bit of fiddling around I have also managed to get full keyboard navigation (via tab key) of the drop menus without requiring javascript, just in case anyone is using Tab without js. The only drawback is that the sub menu links display in isolation (without the ul backing being visible). However, the links are in their correct locations, and as long as they have a background colour set on focus they are readable and fine for use. Note that also calling the ul itself visibly is beyond the scope of pure CSS, so this is as good as it gets without js.
With js enabled there is still full Tab key access available of course, but with the added bonus of the ul backing being visible on link focus like it is on hover. Of course the js also brings configurable mouseout delay for those whose tracking skills aren't quite what they should be, and HoverIntent to stop the menus flashing and/or sticking open when the cursor passes over a tab without stopping. Plus of course you can get animation (which does nothing for a11y but looks cool).
I've also changed the display: none; in the default drops to left: -999em; to make them screenreader compatible without js enabled, and changed the visibility: hidden; in the js to make the menus screenreader compatible with js enabled.
Net result is that for 2.1, and for any 2.0 theming any of us do in the meantime, we can now have a drop menu system that will meet the legal requirements of any organisation anywhere.
Quote from: Antechinus on October 21, 2011, 06:47:59 AM
These menus have been committed in Rev 10827.
We wont be backporting this menu system to the 2.0.x branch, but I think I'll write up a mod and/or tutorial for adding them.
Sounds lovely.
And now -- can you replace "unread replies" with "watched topics"?
And now -- can you replace "unread replies" with "watched topics"?
Why? Unread replies is exactly what they are.
Because sometimes I'd like to be notified about new replies to topics I've never replied to.
Other times, I'd like to STOP being notified about replies to long-lived topics I no longer care about (like mod support threads I offered support on once, a long time ago).
A general "new replies on watched topics" along with a "set watch when I reply" setting (default) would satisfiy "unread replies to topics I've posted in", allow me to stop watching topics, and a "watch this topic" would allow me to set a watch on topics I've never replied to.
It's just more general. Wikis do watches (there's a setting to automatically watch topics/documents when you hit the "submit" button).
I'd be curious as to which of the two approaches would be more resource-intensive.
Other times, I'd like to STOP being notified about replies to long-lived topics I no longer care about (like mod support threads I offered support on once, a long time ago).
A general "new replies on watched topics" along with a "set watch when I reply" setting (default) would satisfiy "unread replies to topics I've posted in", allow me to stop watching topics, and a "watch this topic" would allow me to set a watch on topics I've never replied to.
It's just more general. Wikis do watches (there's a setting to automatically watch topics/documents when you hit the "submit" button).
I'd be curious as to which of the two approaches would be more resource-intensive.
Oh that. I thought it was another minor grumble about language strings. We get a lot of those.
If you want new functionality, something like what you just posted makes things a lot clearer.
If you want new functionality, something like what you just posted makes things a lot clearer.
Do you think that sort of rather dramatic change is feasible? Any idea if it would be good or bad for performance?
Possible. I can see why people would want it as a feature. I'm mainly font end coding, but it doesn't really sound like too drastic a change as far as coding goes (someone else may have a different opinion). It would require more settings and checks though so yes, it certainly would not increase performance. How bad it would be is going to depend on the amount of traffic the site gets and how much grunt their servers have in reserve.
Another thing that I've had grumbles about is the ignore user function. At the moment it hides posts only in actual thread pages. It doesn't hide them in the recent posts, unread replies or unread posts listings. It was done this way for performance reasons. Again, running this sort of thing requires settings and checks and these do result in some penalty. You don't get something for nothing. Every bit of code you run will take time and resources to process.
On the other hand, I can see why people would want an ignore user function to do what it says on the box. A site that doesn't get a lot of traffic, and has reasonable servers, could probably stand the added overhead. A really big site that is pushing its servers hard during peak usage times might not want the added overhead. OTOH, such a site should have tech staff who are good enough to know when load needs to be reduced and how to reduce it. So there is an argument for including that functionality for people who want it.
Another thing that I've had grumbles about is the ignore user function. At the moment it hides posts only in actual thread pages. It doesn't hide them in the recent posts, unread replies or unread posts listings. It was done this way for performance reasons. Again, running this sort of thing requires settings and checks and these do result in some penalty. You don't get something for nothing. Every bit of code you run will take time and resources to process.
On the other hand, I can see why people would want an ignore user function to do what it says on the box. A site that doesn't get a lot of traffic, and has reasonable servers, could probably stand the added overhead. A really big site that is pushing its servers hard during peak usage times might not want the added overhead. OTOH, such a site should have tech staff who are good enough to know when load needs to be reduced and how to reduce it. So there is an argument for including that functionality for people who want it.
The "show new unread posts in watched topics" feature would be a one-for-one replacement for "show new unread posts in topics I've posted to" feature. So it might not make performance any worse. And it wouldn't remove any functionality, either. It wouldn't even confuse the users, if the language strings were written appropriately.
"ignore users even in recent posts" would be a possible default feature, something to be turned off in large/active forums, for the sake of caching. Some of the "23 ways to improve performance" could even be implemented in a single "button" that would throw several such switches to the "optimum for large sites" setting. The "big forum button", of course, could just as well be a mod.
"ignore users even in recent posts" would be a possible default feature, something to be turned off in large/active forums, for the sake of caching. Some of the "23 ways to improve performance" could even be implemented in a single "button" that would throw several such switches to the "optimum for large sites" setting. The "big forum button", of course, could just as well be a mod.
What has been posted makes a great deal of sense. SMF should continue to engage the community at every point and involving them.
As the community becomes more involved I am sure extra help will come with that too. One of the next great ideas for future generations of SMF is a hook based system for mods.
Either way - a great post and good news for everyone.
~RedOne
As the community becomes more involved I am sure extra help will come with that too. One of the next great ideas for future generations of SMF is a hook based system for mods.
Either way - a great post and good news for everyone.
~RedOne
Like and Dislike and rating tools for posts and members