Wedge

Our current header is:


11 lines, 265 bytes.

ASF's is:

15 lines, 798 bytes (including spacer line). That can be shortened too, since the licence by definition would include the warranty status (which is the second paragraph), so it would just then be the first paragraph and version number, perhaps:


11 lines, 448 bytes (including spacer line) assuming the licence changes as has been suggested and if not we then refer to it as Wedge licence instead, but you're talking about a few bytes' difference.

Actually, Arantor, we do agree on that bit.

I think that SMF should change the header to indicate that the copyright and license (two different things) are defined in single, separate files. (for the same reasons that you mention (no need to change individual files each year/release...)

So if we agree, why are you complaining about what Norv did, which was essentially an attempt to enact what we've been talking about? I won't argue it wasn't done correctly, but the sentiment was there ;)

Mind you, I'd love to see what a legal person makes of all this, because I'm not convinced your DCO gives SM the rights they think it does, and I'm fairly sure that there's legal issues with claiming copyright even over the entire package.

Even we can't claim copyright over the entire Wedge package, only the differences in code between SMF and Wedge.

Well, we agree that the license and copyright should be in a separate file which is reference in the header rather than being defined in the header of each and every file/
What Norv did was not switch the license and copyright to indicate "see file"
What she did was change the copyright line attribution.

(actually, if we had originally had the copyright point to a file, it would not have been quite so big a deal...   someone could have gone and done a re-commit of that single file rather than trying to back out the change made to every single file in the package.

As for the legal matter...   you may be right (and, in which case, there are several other issues that need to be taken up within the team regarding the switch to the DCO and lying about what that did/does when they requested it)
Agnelina is actually talking with lawyers to get a definitive answer...

Ah, so we agree on the method but not the substance.And therein lies the problem. I'm just not convinced you *can* say that any given file's contents actually are held by the team copyright.Wait... you switched to the DCO months ago (June, wasn't it?) and only NOW you're getting legal advice on whether it might be legitimate?

And you wonder why I say SMF is dead. It's doing so well to shoot itself in the foot. I can pretty much tell you what the answer will be, too, and it will be in line with what I've been saying.

My free armchair-lawyer "legal advice" equivalentIt's almost like the team didn't talk to the developers about what the developers were doing, but apparently that never happens?

no... actually, it's more like certain folks mirepresented what the DCO was.

but anyway...

Alright, so let's say they did. I'm not certain that was what happened, but let's say for the sake of argument that they did.

No-one thought to get legal advice? No-one thought to double check? No-one thought to clarify the differences?

From where I'm standing, they would have to be worse than second-hand car salesmen to misrepresent it so badly that it was accepted on the basis you're implying. I realised on first reading what the problem would be... and I only play a lawyer on TV.

Sorry to butt in here..and I am sure Kindred is fed up heh, but I can only nod to what when Arantor has to say about the state of things. This is not a new scenario, and while its a good while since I was involved, its hasn't improved since the mess that was Amacythe++ was around, well, not so much you would expect anyway. Talented devs still leave, less talented stay and eventually, leave too...

Its a clear pattern here, and no "i don't see how they can say its wrong" will make that different. It reminds me of something..excuse me for my poor memory, fighting windmills guy? lol, anyway, if you want to stay in your belief that devs are just stubborn and drama queens, by all means do. Its a slow death for SMF and has been for some time now.

It seems that Arantor and Nao are the only ones being still standing in the forking aftermath of SMF going BSD..but I feel several others haven't quite left the arena yet. Elkarte enjoys some former devs enthusiasm,and thats good. Building something is always good, and I strongly believe many of them(certainly myself - although i stayed with my own devices) ENJOYS not being "steered" and "controlled" and most important, feeling they would just be doing the dirty work.

So yeah..maybe it isn't possible to run SMF like a corporation where things get decided and people are told to do stuff. Maybe its best to let it die, so new forces can flourish and be free to change, to try out, to INNOVATE. It certainly isn't "innovative" that comes to mind when I see SMF these days.

ok, I'll be quiet now. :P

It's just a bit sad to let the 'SMF' brand die, somehow. I still like it, just as much as I like my own 'Wedge' brand... (It's just that I'm not a fan of how the product is managed, to begin with.)

Pete, I don't think that ~200 extra bytes is short. Also, an extra line is needed at the beginning (/** isn't just there for show, technically... :P)
And we can't really remove our file description, either... I'd say.

We could get rid of @version, though. It's a SMF thingy, we never really took care of it, and I don't know if it's ever gonna become useful to us one day.

Bloc...

See, this is the thing I don't understand...
The dves have never been "steered" or "controlled" by anyone (except maybe their own dev lead)
Others have expressed opinions on what was getting added (or removed) and may have requested that something get added...   but no one, to the best of my knowledge has ever tried to tell the devs how to code... or even what to code, once the "desired feature list" was discussed and decided on... and AFAIK, the devs have always made that decision (even if it realistically should sit with the SC)

the people complaining (former devs) all seem to be saying "I can't work like this, I can't have people telling me what to do and how to do it" --- but I have never seen anyone actually DOING that to the devs...   The closest we non-devs have come to that was insisting that the rets of the team has a right to give our INPUT on what we think should be added (or removed).

Its a pointed argument - its never as black and white as that, and I am not saying it was that all the time either. Its just enough of it, to make people leave.

A correction, while I generally don't like management lol, its NOT to say I won't respect others decisions on where to go. its just that, the respect isn't there. Maybe because of poor decisions made, maybe of people talking about stuff they are not doing themselves and so..its not about working together, thats is a good thing, its about -managing- people, the thing you do Kindred, or at least encourage.

This is the part I'm trying to hammer home, so to speak. If everything is supposed to have changed with the introduction of the NPO, why is it people are still leaving at a horrific rate, and *still* saying the same things about why they're leaving? The only conclusion I can draw is that it isn't the name of the organisation or even particularly the way the organisation is run, but the way in which the non-devs interact with the devs.Devs are stubborn. That's par for the course. I have never met any developer of any standing who wasn't stubborn, because it takes stubbornness to learn the skills and do the job. Drama llamas? Yeah, I'll agree with that, with one caveat. I do drama a lot, and only some of it is pure drama, some of it is a baiting tactic to provoke change. I recall doing this in October 2009, threatening to leave the team without any intention of actually doing so, specifically and clearly to try and unite everyone in something approaching a common cause, and for a short time it did actually have some small improvement in unity and working together.

Thing is, devs aren't like everyone else. We do what we do because we enjoy doing it, like any craftsperson out there. Our passion is there - but the nature of what we do as coders implies that we don't bring the drama out, the passion, in the code itself. It's like we have all this emotion built up from doing it, but we have no release mechanism from actually coding, if that makes sense. Or at least, that's the theory that's made sense in my head and the folks I used to work with at Lehman Bros had much the same take on it, those that cared about the code, anyway; those who didn't, were there purely to earn their daily dollars, in which case you just sit down, shut up and get on with it. The result is code that is workable but nothing wonderful.

As I said, devs - and I do include designers in that - have egos. We put ourselves into what we do. I won't go as far as to call our projects our 'children' but there is a progeny thing going on, they are the product of us, our time, our energy, our passion. Excuse us for caring about what we do and wanting to see it done how we feel it should be done.Wedge is one of the strongest standing - but also the longest established of the forks, and the two do go hand in hand. A number of them fell by the wayside, partly because of life concerns, partly because of a lack of appreciation for the scale of work required to make a fork.

And you've hit the other nail on the head. When we're the ones at the rock face, we like to set our own path to an extent, to go where it takes us.

I'd be forever feeling like features I could add to SMF would be not entirely in keeping with the 'I'm a forum' aspect that SMF has, so I'd be very much of the feeling of being steered, into building what someone else wants and not what I want.Yup. It isn't a business, it shouldn't be run as if it is one. But it suffers the same problem I've see in a number of businesses. Dilbert strips come to mind.


I would reply further to what's been saying but I get the impression I'm talking to a brick wall. Already today someone has asked me why you can't take your blinkers off. You're not able to see it the way everyone else is. So let me turn it around a bit. Has anyone told you how to do support? How many topics need to be done per day, or that you need to approach them in a certain fashion, or asked you to concentrate on a specific subset of support? Anyone asked you about there being a certain number of unsolved topics?

The answer to the above should be no, no-one tells you how your contributions should be given. And you get appreciation for what you do. Devs don't get appreciated, it's just a round of complaints when things go wrong, and all the things we've talked about that as far as you believe aren't happening.

well, yes... I am a project manager. :P

but seriously...  I have always believed that it is about respect and that it is the leads' jobs to manage the people on their teams.
The thing I have been trying to get SMF to understand is not management of PEOPLE...  it's management of activities and expectations

You can lead a horse to water etc.

But you can't manage expectations and activities in a volunteer organisation the way you would in a business. You can't sack them, you can't dock their pay, you have to nurture their interest, not beat them with a stick.