Wedge

- what Arantor said. :)

People are here on their own time, its not a job, most of us have that already. So..in order to make things work, i believe everyone must feel that, that we are all peers in the sense of everyone agreeing and - most important to me - acknowledge that "yes, some things I know better than you, so let me try it at least. I am here for the fun, don't spoil it."

About devs being actually stubborn etc...I guess thats true. But it can be both things, positive as well as negative, one can work together and still be a bit stubborn just to make things progress. See, thats again one bad thing about coming from the angle that one has to be managed, that ideas has to be managed: sure, there can be people that decides things. But I would never just sit and decide something i know little or nothing about!. Very acute example, in all the time I was on the team, I did not tell the core devs to change how the core was done - because I didn't know enough about it! Same with javascript, I would rather ask for help. its actually not until now i can at least say something about that, it had to be learnt first.

But if someone said they could do better in terms of the theme stuff back then(and now lol), I would/will have little patience if they didn't actually know something about it. I mean, I can't respect someone that never made a theme in their life, yet proclaimed they could mange other designers or theme devs on where to go.

But again, its not a black and white process, as a fellow Libran I am sure you see this, Kindred. :) It is a limit for everything though, and that limit has been crossed too many times in the SMF camp IMHO.

-sigh- The bit you're missing is what has happened every single time in the past with the project - and I went through the entire team history.

Every time the team decided on a date historically, it was management saying 'we'd like it done by x', usually without actually consulting the devs to see whether it is feasible/practical/doable or not. This is where it starts.

Then when it doesn't happen, there are recriminations, guilt trips etc. and then developers decide that contributing to a volunteer project becomes worse less and less.

If you ask the devs what date they consider feasible, you might get a meaningful answer. However, in the build up to that date, there are going to be 'is it ready yet' questions and in the aftermath there are 'why is it not ready yet'. That's what happened every time in the past, that's what will happen in future. Which then makes you wonder why you bother with a date because everyone who is not a dev fixates on the date and harangues the devs to try and make that date.Me three ;) But yes, this is where we're at. Too many times it's happened and the fact there is this shock/horror response to it being brought up says almost as much in itself as to how much of a problem there is.

Ah yes, dates, the horror of everyone that are trying to reach it I guess. But yes, it is useful, as in the people working towards it actually setting it(because they will most likely WANT it, why else are they there? If they are for other reasons it will soon show anyway)

Its not an easy solution to this when it comes to SMF(and all of us here have invested a lot of time too, to just easily skid away, still here, still arguing lmao :).) ...and it may be way too late overall. But at least know that all of the devs that left, that left BECAUSE of the team and not for personal reasons, didn't actually want to. But what can you do? The fun must be there, I don't particular like to feel bad when I join projects, I might if I MUST, in the case of RL work perhaps - but even then its some leeway towards saying "I can't work like this".

This. This, so much.

so... Bloc,  this has been asked before, but I have yet to see an actual meaningful answer - what would make the team fun again?.
(and the only answer is have really seen was "the devs are the only ones that count, everyone else needs to stfu and since you won't stfu, we're leaving" (and yes, someone said, essentially that))


I understand leaving a project because its not fun. That's why I resigned back last spring.
and the only reason I came back was because k@ and Liroy kept asking me to do so
(and aside from the copyright debacle, I have been trying to stay out of the politics, etc)


but... back to the question.
If the devs left because they weren't having fun... what would bring them back to have some fun?

I honestly don't know. There's been so much in the past that it's hard to actually imagine writing code for SMF that is fun any more, especially when I consider, for example, the comparative joy I have of writing code for Wedge to anything I ever wrote for SMF.

For example, I can go off and if I decide it's necessary, I can go away and rewrite core routines and do all kinds of crazy. I'm in the midst of rewriting the ban system, most of which doesn't look like it's been touched since 1.0 or 1.1 other than visual changes in 2.0's templates, and I decided I was going to up-end it and redesign it to cope with all the things I wanted to throw at it. Would I *ever* have been able to get away with that in, say, any part of the 2.1 development? None of it is 'strictly required' and being conservative was not on the agenda, it's a huge rewrite, and it's been a lot of fun in doing it.

Arantor...

and that's exactly what devs SHOULD be doing... in a semi-planned fashion.

As you say, it's a huge undertaking, so it would not have been proper for 2.1, which was determined (at the outset) to be a release with new functionality but somewhat limited in major revisions.
However, saying "I want to do this" and putting it in a path for 2.2 (or whetever the next major release would be) would be completely appropriate and I can't conceive that anyone on the team would try to stop you from doing that....

That's the problem. You want to regiment it. But you can't regiment something that's creative, and that's why it's not fun.

In this particular case, I'd have been fighting tooth and nail for it to be included, because as far as I'm concerned, it's necessary. The complete redesign allows for three things that can't be done by an incremental change on the current setup - improved performance with many bans, proper IPv6 support and support for + filtering on emails. I also wanted to add the equivalent of annoy user, and refine all the interface to make all that sensible and efficient.

But essentially what you're saying is that I wouldn't be able to pursue something worthwhile because it doesn't fit within the conservative way of development. Even if it had been proposed at 2.1's outset, I'm not sure it would have been accepted for inclusion because 'if it isn't broken, it doesn't need fixing'.

Everything that's happened has been around incremental changes, not radical overhauls, and sometimes you just have to toss it all out and start again, and that's ultimately where the clash is.

Arantor...  I actually agree with that last statement....   And if it had been proposed at the start of 2.1, it may have been included... but 2.1 was, very purposefully and intentionally designed as as incremental, minor release. (muchly because of the timing, but also because Norv declared that she didn't think that ANY further development should be done on the 2.x line at all. Spuds and emanuele opted to step in and do some work on an incremental release (2.1) while the rets of the devs were SUPPOSED to be focused on SMC/3.0 (per their choice, not because the team said a word)
And I'll say, it was more than a good thing that they did that, considering where SMC has gone........

However, you seem to think that ANY restrictions are regimented...   while I would argue that - be as creative as you like - but we need to consider things other than pure creativity and SMF can not go another 5 years without a release.

Seriously, an iterative approach is pretty straight forward and good for the SMF plans...
work on things for 2.1 that can be done in the time and with the resources we have.
plan or work on things for future releases as determined by the workers.... when it comes time to think about a 2.2 (or 3.0, or whatever) then you step forward and say "HEY! I have this great update that I made to the ban system. Let's drop it into the next release!"
That way there is both organization AND creativity.

What you are doing with wedge is great. You and Nao are amazing coders and (despite any disagreements that I have had with you :P ) pretty decent guys, and wedge is awesome! ... but you're still working on alpha and you don't actually have any community of users to support - so it's a slightly different model from the mature product that SMF currently is.

See, here's the problem... I've been trying to figure out how to overhaul the ban system for that long. It's needed an overhaul and it's only now that I figured out how all the elements of it have to work together. The equivalent is saying at the start of 2.1 "Hey folks, we need to fix this, any ideas?"

I have the freedom to do the most insane things here - and if you read my notes on the package manager replacement, you'll know that some of them are pretty freaky indeed...Mature or stale? :P That was a bit catty, wasn't it? True, we're not working on a currently stable release. But the goal is to refit enough that we can be 'stable' for a while without needing to get into major overhauls later on.

I hear what you are saying...   you can indeed do wild and crazy things without much thought for consequence or timeline right now...

SMF, on the other hand, DOES need to think about timelines. the gap between 1.1 and 2.0 almost killed it....  we all know that.
So, interim releases like 2.1 are necessary...
just like it is necessary to fix things that need to be updated (like the ban system)

Even in the model that I illustrated,  the devs have the freedom to do things like that...   the main difference is that the actual inclusion back into the trunk needs to be planned rather than just "done"

I get where you're going, but sometimes you need to go wild and do crazy things even on incremental releases. Take 1.1 for example - the bbc parser was completely rewritten in what is conceptually an incremental upgrade, because it had to be. And if that isn't a wild and crazy thing, I don't know what is.

OK, I'll give you that...   and that can actually even be factored in by the dev going to the dev lead and saying "I've looked at this... and it really needs to be fixed". The Dev lead then goes to the SC and says "We have decided that X needs to be fixed in the next release. We expect this will push the plans out by at least 2 months"

See, there is still ROOM for creativity and even for last minute additions.
Heck, I do the same things even in my real business projects. The devs (or QA) comes to me and say "We found something that needs to be done" and, as PM, it's my job to communicate back to the customer (or management, if it's an internal project) that the date is going to slip, but it's for a good reason)

The whole idea is to START by working towards a plan, though...  That way, you have a goal, with an end "in sight"

I'll note - Agile/Incremental Sprint releases are even easier to handle this sort of thing (even though the SMF team has violently rejected any suggestion of agile) because you're working in much shorter timeframes than years or even months.
At the start of the sprint - what can you get done in a week? How about 2 weeks? Anything going to take more?
and then, as each sprint ends, you plan the next 1-2 weeks (plus anything ongoing left over from the previous sprint)
You draw form a list if things which should eventually be done (the backlog) and take what you can or want from the list, commit to an (estimated) timeframe and go with it.
Yes... we all know that people can't be HELD to a timeframe in this sort of project... but once again, working toward a goal means that you know where you are going and what you have promised to do (and so does everyone else in the sprint-team). and goals ca be adjusted much better in a 1-2 week sprint than in a 6 month push (when, at the end of 6 months, you suddenly find out that something wasn't done, or something got changed that should not have been)


Anyways... this is all just me rambling on what I *THINK* should be done or how it could be handled. I am (more or less happily) back down in the support ranks again and have no actual power to affect anything.  I'd just like to see
a- some developers come back or new ones start - with this sort of thing in mind
b- a strong PM and dev lead who will actually lead AND work together

(as opposed to what happened with me and Norv, where she wanted all the power and felt the PM should basically be a figurehead or what happened before where the PM tried to rule the project with an iron fist...  or what we have now, which is no good dev lead and (essentially) no PM.)  All of those models are wrong.

 

Yes, there's room. But it's not fun. It's hard work, it's stress.

I just figured out what I was going to, I then set out a post saying that it was what I was doing, and kicked off on it while waiting for feedback - I already knew where I was going in general but deliberately allowed for feedback to change it. But there's not one or two layers of bureaucracy that I have to wait for before I can do anything - because I'm not going to burn time if I can help it on something that I might not be able to use.And why? Agile is easily the most approachable form of development for something like this, IMHO. It allows people to make small and focused changes. If you look at the features I add, a large number of them are easily characterisable as agile.I won't argue that a is a huge problem. No-one with history wants to touch it with a barge pole, and there's not even anyone coming through with the maturity as well as the skills and experience to make that happen going forward. There are some wonderful folks coming through like Yoshi (because as much as he can irritate me at times, I can't fault him for enthusiasm, what he just needs is some structure to what he does, followed by a little maturity and a couple more good years at it), and then there are people like Lab.

b is a much bigger problem. Norv is very much one of the all-or-nothing people, and that's not going to work. I'm much more in the middle; I've never advocated the devs having *all* the say even if they're doing *all* the work, and that's the route we take - we have the main say but we do navigate the path of what people are suggesting too. I'm fairly certain we wouldn't be where we are without some of the discussions and ideas from outside 'us'.Yup, no good model there. I agree on where SMF needs to be going, but because of all the past stuff, the only people who ever stood a chance of being the people SMF needs up top have been pushed out because they didn't fit the way things were going. I will admit to being one of these - at the time I left, Amacythe's power grab was just about to land, and all I've seen in the intervening time is essentially what amounts to closing ranks against the people who might make a difference.

The folks up top have to have charisma. They need to be people people as well as coder aware people; the lead dev needs to be a strong coder with a strong personality, while the PM needs to be a person with an even stronger personality, and ideally with some grounding in code, but I wouldn't make that a requirement. Ideally the PM should be an active contributor, not just from the sidelines - a PM that is a coder is almost ideal.

I think that's why Nao and I work as well as we do, because we're both essentially both roles. We do move back and forth between the two, but ultimately we cover both roles.