Skip to main content
Topic: Open Letters to the SMF Community (Read 9983 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Open Letters to the SMF Community

Reply #15
In the past they have let most requests for deletion go for 30 days before fulfilling them. There's been some exceptions, but for the most part is has stuck to that.
Success is not the result of spontaneous combustion, you must set yourself on fire!

Re: Open Letters to the SMF Community

Reply #16
TBH I've happened to ask, and I was told the team doesn't even know of TE's request. (or didn't.). Not to mention he didn't get an answer.

Also, sometime lately, a number of threads from 2009/2010 have been all moved out of SMF Friends view. Y'know... the LLC vs NPO issues.
Fun bit for you: I was just re-reading them, when they've been moved out of my view. At a refresh of a page. Purely coincidental, I reckon. :)

And, I understood that public topics from sm.org pointing to *this* thread have been removed.

I'd have to qualify the actions as closing in... in case it'd matter.
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: Open Letters to the SMF Community

Reply #17
In the past they have let most requests for deletion go for 30 days before fulfilling them. There's been some exceptions, but for the most part is has stuck to that.
That's IMO a joke.. why should I wait 30 days? That's stupid. I'm finally done with SMF and the SM organisation and I'm sure not to return or to contribute code.. I've reactivated ny account, deleted my personal infos and marked for deletion again.
 TE is tempted to write a small script in order to remove text and attachments from his old posts..
Thorsten "TE" Eurich
------------------------

Re: Open Letters to the SMF Community

Reply #18
Account deletions used to be processed only after 30 days.


Re: Open Letters to the SMF Community

Reply #20
Yup ... another very poor attempt at listing names, is it really that hard to knowledge the folks that contributed code to a release? ... love the SM and SC decided comment  ::)

Re: Open Letters to the SMF Community

Reply #21
Did you guys notice the contributors file at the end of that with everyone in it?

Re: Open Letters to the SMF Community

Reply #22
Yep, and I think we should decide what to do with the credit page we too.

 emanuele hides
Bugs creator.
Features destroyer.
Template killer.



Re: Open Letters to the SMF Community

Reply #25
Question: if you're using Github, that only shows the GH contributors, not all the contributors in total, which means it doesn't include any contributions prior to Github.

Considering that you're calling us out for removing ex-devs credits, how does it work that that's essentially what you're proposing? Or do the SMF team contributions prior to ElkArte's formation on Github not count?

Seems a bit hypocritical to me. (And I'm one of those people who is trying to just list everyone, dev or not, that contributed to the project. I'm all for crediting contributions regardless of what badge (or not) they held at the time.)

Re: Open Letters to the SMF Community

Reply #26

Question: if you're using Github, that only shows the GH contributors, not all the contributors in total, which means it doesn't include any contributions prior to Github.
That's right in general but I think SMF contributors have already been credited by holding SMF's copyright inside the files (Elk is based on SMF which was made by the SMF contributors) Either way, I'm fine with whatever we do..
Thorsten "TE" Eurich
------------------------

Re: Open Letters to the SMF Community

Reply #27
No harm either in keeping them, I think the contrib file is a good thing to do. SMF's one should be a good starting point, we can trim and add as needed according to our own list of contributors.

Then, the credit page can be used to list the active contributors or something like that.
Bugs creator.
Features destroyer.
Template killer.

Re: Open Letters to the SMF Community

Reply #28
The ElkArte contributors are just that, those listed on GitHub, link it, we could also add the list at a release date if we wanted something static showing as well.

For the base code which we used to build on, we could add another section that makes special acknowledgement of that project and its members. To be safe we could just get the 2.1 list (whatever is decided) and use that.

Re: Open Letters to the SMF Community

Reply #29
Posting here so that I'll not disturb further the person that posted it.

The post is not intended to collect +1s, or to make people change their mind, or whatever.
It's just something I feel I have to voice, at least to fix it in my mind.

Apparently one can't make mistakes... eww, I would offer the same "help" back but I don't give a rat booty about other projects nor do I wait to know what other people are doing so I can "borrow" it... I mind my own business... you should do the same...
I just want to say, that regardless of any disagreement, what I always tried to (and I'm still trying to) do with all the SMF forks is to maintain a certain level of collaboration (Arantor and Nao should probably be able to confirm, and the fact I was an SMF dev until a month ago should demonstrate it as well, but I suppose it could also be used to demonstrate I was trying to take advantage of my position to put ElkArte in a better position [1]).

I find the very idea that I should mind my own business quite offensive, for what I tried to do in the last year or so.

I also find it offensive because is quite the opposite of what usually "Open Source" means: Open Source means collaboration, not fighting between projects because "I don't want to touch your code because it's yours". Are we so childish?
There is code, good code? Fine, I'm going to use it as long as the license allows me to. You may think it is hypocrite, well, to me it's not. It's just another way to show respect for your work: admins use the software, I use the piece of code I think it's worth being used.
What's wrong with that?
Are you scared by the fact that Elk code may poison SMF code?
Is the code we write infected like some kind of artifact[2]?

Finally, I find it stupid (sorry if you are going to take it as a personal attack, but that's what I think) because "mind my own business" means for example that if someone reports a security flaw in Elk that is applicable to SMF as well, I should "mind my own business", fix it and publish the fix, potentially exposing all the live SMF installs to a 0-day attack. Is that what you would like to see? I guess not... I hope not. And sorry, but I wouldn't be able to "mind my own business" in such a case.

Well, that's all.
Sorry for the noise. ;)
The idea that someone would have been able to think something like that was the main reason I never even considered to accept the dev-lead position or any other position involving some kind of responsibility
/me is watching warehouse 13 :P
Bugs creator.
Features destroyer.
Template killer.