They *are* being used. Everything that happens there is it, basically. That and in the trackers. Please give us statistics detailing stuff that didn't happen there but should have happened there instead.

Again, if you feel *more* should happen there, I agree. But not because now everything is happening hidden, but because more could be done with core development in general.

Oh, and you misread the sf.net method of displaying threads. The threads are shown based on the time the discussion started, not on the time of the latest post in the thread. So there has been happening a lot more then just your thread.

Herko

Quote:
No, that's it right there. The last thread is yours indeed, but there are other threads discussing many differnt aspects of core development. If your point is that there should be more discussions, then I cant provide a link for you. It's not about quantity tho.

Oh, and thje core dev team probably uses IM a lot too. And the trackers provide a lot of information as well.

These are all very common developers tools. They're simply used...

Herko

Quote:
The fact that you haven't seen those discussions, doesn't mean they haven't been there This is exactly the point in case. In my personal experience, there are valid reasons why some discussions should be held in private. The ability to think aloud, and disagree i private, to brainstorm without holding back, to negotiate. To prepare and plan, to work on drafts, to discuss propositions and proposals. In all of these there can be valid reasons to hold them in private.

Ignoring them and holding to the principle of 'everythigng public' isn't constructive debate. Giving valid and motivated arguments that oppose them is.

Quote:
Please, read the posts made here. If you don't know what is going on where, you will have to look. The sf.net forums are the place where this is being discussed. In recent days, more actively, thanks to the efforts of some developers.

And you ask for a timeline. This is exactly why some discussions shouldn't be in the spotlight of the public eye. To use an analogy: the developers are discussing a concept car design, getting down to the main principles and architecture. And here *you* ask when you can buy it. That's totally out of the scope of current development.
Besides, if you as project lead can find a way to manage the common pool resources to develop the XOOPS core to the highest possible standards (the same goal the current developers have), with the volunteer work being done, you'll get everyone's full support. But asking for a timeline in this stage of development with such a low availability of the resource pool, is totally besides the point.

Herko

Quote:
Eric, I appreciate the offer you're making (and I'm definately not trying to dissuade you!), and also appreciate this discussion.

Quote:
I'm all for transparency, but some things need to be prepared behind closed doors. Heh, if you're married, you'll understand
Seriously tho: it is a proven fact that where there's different interests that need to come together, there needs to be compromise. And where there's comprmise, there is negotiations. Ask anyone, but public transparent negotiations don't work.
I'm all for transparency, and propose this guiding principle:
in public, unless there are good reasons not to do it in public. And make those reasons public, so people understand.

Quote:If this is to be the case, then how do we decide who are members of the community? Everyone? Only english speaking members? Registered members? Known users? People who contributed? People who asked only one question? Former users?
I think you'll soon find this doesn't add much value to the process you're trying to set up.
In fact, I think that NO LEADERSHIP for the community is MUCH more powerful then having a democratic/meritocratic system put in place to emulate a non-existant reality. Without leadership, everyone is a leader, in this community. How's that for 'Powered by you!'.

Quote:
The sf.net site is a mess? Hmm.. it's the developers workspace, nothing more. So yes, core development should be focussed on the sf.net site. But the rest shouldn't be there. It'll distract from the development.

Quote:
Read the previous posts: these are the core development leads. Not the XOOPS community leaders, or the overall project managers. Well, they *should* have been, but obviously haven't been.

Herko

Quote:
As James wrote in another post, the sf.net project admins are core developers. They're the development project admins, not the community support admins. IMHO split these two apart, and the whole leadership issue becomes easier to solve. The core development already has leadership, it's the support community that lacks it. IMHO, this isn't a bad thing per se.

I'll give you my input, which may seem sceptpical, but this is based on 3,5 years of XOOPS management experience, longer then anyone here.
Quote:
All XOOPS decisions are made in public --> All XOOPS support community decisions are made public.
If you stop and think about what decisions we're talking about here, then these are mostly practical issues on who does what with news, moderators, FAQ and such. This doesn't really require an overseeing and coordinating leader IMHO. See points made in previous posts in this thread.

Quote:
First it was docs.xoops.org, then xoopsdocs.net, now the sf.net wiki. A lot of talk about the location and tools used, but what about the actual writing of the docs? Who cares really where they're made? It's about writing them...

Quote:Core development team decision. Simple. Why would an overseeing coordinating project leader need to make these decisions on how the developers do their work? If svn and cvs are necessary (and its the developers who make that call anyway), why don't we let them keep it? Parotting experts decisions and making them 'official' is one of my own mistakes, and I propose everyone learns from them

Quote:
Again, a developers call, not a community leader's call. This is a change? See the trackers and forums on sf.net. It already works like this.

Quote:
Pfff. If this should come from a leader, it sounds patronising. Don't get me wrong, I fully agree with the point, but that's like saying 'If I get voted in, I'll say that you have to abide by the law'. It's about how you intend to keep people to their promises and how to keep them from misbehaving. That's what leadership means IMHO.

Quote:
Nonsense. People don't vote because they're more comfortable, they vote to make themselves better. Since when did anyone vote for the Greater Good? And then vote on what? Vote on who will do all the work? Vote on what needs to be done? Then what? Voting isn't the answer.
I'm with the meritocraticists here. See my previous posts.

Quote:
Been there, done that. This was called the Core Team, then the Management Team. Honestly, it's all been done before. And I don't see what will make it a success this time.

Quote:
The last 6 newsletters would have said 'On Hold, please check back later'.
This however is a good idea (and again, definately not a new one). Find out why the current World of XOOPS newsletter isn't reanimated, and you'll know what to fix. But it definately wasn't a lack of communication by the management.

Quote:
IDOLS ALERT!

Seriously, the temporary bit I like, the voting bit I hate. Better way is to have the period set by the goals that need to be achieved. Like: XOOPS 2.3 released, 20 new documents for users, 5 new core developers, 75.000 registered members, 2500 daily downloads, etc. If they're reached, the community will discuss new goals. And then the method of reaching them is decided.

Again, IMHO ther eis no need for an overall encompassing coordinating leader at the moment. What we do need is active core evelopment, which is already happening (see the trackers for this). What we also need is new life in the XOOPS Foundation so real work can be made of the corporate side of XOOPS: marketing and promoting the XOOPS product to the masses. And the community needs to stop looking for other people to do the work for them

Herko

Thanks for the honesty in this thread, it's very invigorating. 'My' leadership model worked when 2.0.x was just released, and the community was only just starting to grow. When I started XOOPS.org had 8.500 members, when I quit, it was 45.000.
But I am no developer, and XOOPS needs development to keep alive. So I was trying to create a way that would ensure that this could happen, without me as project manager. Skalpa just forced this to be a bit sooner then I anticipated.

Now, back to this thread. Leadership is a very important thing. I'd like to pose a question.

What is the XOOPS project really? IMHO there is (core) development, corporate communications, (international)community support and 3rd party development.

The first, core development, already has its leadership model. This is the open source software development model, and is pretty straightforward. There is a lead developer, who doesn't need a body of people trying to influence the work of his team. Anyone can join in development, provided they add to the pool of resources.

Corporate communications is a task for the Foundation IMHO, as the official representation of the XOOPS project. It'll need more members of course, and a way for the community to be able to participate, but I already have that prepapred. Pending this discussion here, I'll call for new members real soon. So there's a leadership structure ther as well. The Foundation itself doesn't lead anything, just support the project.

International community support is what happens here on xoops.org at the moment. Support forums, FAQ, documentation, training, that sort of thing. What kind of leadership does this need, really? Any structural leadership? I can't think of anything that needs structural community leadership. We'd need moderators, reporters for news, maintainers and editors for FAQ and such. But a leadership structure, IMHO no.

3rd party development of modules and themes is by definition outside of the leadership structure of the XOOPS project.

You don't have to agree, but I'd like to see where and why you disagree Maybe this will get us closer to a more suitable (and ultimately succesfull) leadership model for the XOOPS project.

The 5-headed dragon that is proposed has failed 3 times already, as Core Team, Managament Team and whatever followed. I don't see why it would work this time

Herko

Anyone who wants to give managing the XOOPS project a decent try will get my blessing. So I support this thread.

Here's a couple of points to take into consideration when coming up withthe best form and method to manage here. These are from my ample experience and professional opinion, so please don't dismiss them offhand.

About democracy. Democracy is good, but in too many posts I see only a single sided view on democracy within the XOOPS project. Democracy -where I live- also means paying taxes and abiding to the law, and that those people put in charge make the final desicions without your further approval. This is indeed no direct democracy but a representative democracy, but mostly this applies to direct democracy as well.
Now, applied to the XOOPS community, this would mean that there'd be a way to define taxes (what does the community need to give in order to have the democracy work properly), and for everyone to abide the laws laid down. At the moment, I don't see the community being taxed in any way, nor do a lot of people abide by those few moral and ethical laws that we have laid down in the XOOPSiquette and the GPL license.

And then there's the discussion of democracy vs. meritocracy. Meritcocratic decisions are made by people who have proved that they're capable and worthy of making those decisions in the past. Sometimes the XOOPS project has shown itself capable of working as a maritocratic project. But nowadays all I see is personal attacks on those that have stepped up and little to no real discussion. In short, a huge amount of drama, but very little storyline. Having been (and still being) the brunt of those personal attacks, I can say that this is deeply demotivating, and has an adverse effect. Why would I listen to what those people attacking *me* have to say? I've never been one to shun a real debate, and if the outcome isn't in your favor, live with it. That's whateverocracy. But if it is, you get all the credits. That's how I've tried to work, but some people don't think that is enough. They're right, and the world should know and recognise that.
My point here isn't my bitterness or disappointment, but that this is a fact of life for this project. The loudest get the most attention, and this is often mistaken as 'the will of the community'. If you're going to manage XOOPS, you'll have to find a way to deal with decisions not being questioned at every turn. And that the decisions are made professionally. Sometimes, the will of the community isn't good enough.

Another point I'd like to give you is about transparency. This is a huge issue. I've probably set the bad example there in the past, but I definately wasn't alone in this. You see, when it comes down to it, everyone wants the other to be as transparent as possible. But when it comes down to self-transparency, there are a lot of reasons why this isn't possible or wishful. Transparency is also vulnerable, and doing that is difficult at the best of times.
A very wise man told me yesterday that if you have transparency at the top of your list, your aim is to become invisible. Because, when you're fully transparent, nobody will see you. Now there's a conundrum. True transparency means no need for roadmaps and plans. No need for deadlines. No need for teams and communications. Because everyone would be able to find out for themselves. So, then there'd be no need for the XOOPS project (meaning as an organised project, not as an application).
My point here is that if you're going to manage any project, you will need room to think, discuss and plan. You need a place to negotiate, and when everything is out in the open, there's no room to negotiate. In fact, as soon as there are more then one interest at hand, you will need room to coordinate and plan. When is the best time to release this news, what steps are we going to take, who will finish that part of the project and let everyone know...

Then there's the point of scale and dimensions of the organization. WHat is the Community, and the Project? Are they the same? Then why is there a staff of people that should do the work for the community in the name of the project? Who gets to decide how the application develops, and how the community itself is run? Who gets the power to realise things on the websites? How are those decisions made? How do you deal with conflicts, and how do you keep people to their promises? Who gets to say what is in the best interest of everyone? Who gets to vote? ANd vote on what? And why?

These are not easy issues to solve and do right. They're at the heart of the problems we now see. I'm looking forward to seeing real solutions and a lot less drama and shouting at everything. This means less ego.

Now, as a last point I'd like to plug the XOOPS Foundation here. Please consider how this would fit into your plans. It is there, and has been working behind the scenes on securing the continuity of the XOOPS project, whichever way it will go. The Foundation definatley does not lead XOOPS (nor should it, ever). But is is the only legal representative of the XOOPS project (not the community), so use that properly.

Herko

Actually, these modules (as it is a module set) have been released from the very first start. They haven't been kept updated tho. You can find the project and its files here:
http://dev.xoops.org/modules/xfmod/project/?myxoopsforge

And Novell has made their own XOOPS 2.0 version of the XOOPS Forge modules, and dubbed them Novell Forge. These files are available for download as well. You can find those files here:
http://forge.novell.com/modules/xfmod/project/?forge

Both projects have been abandoned tho, so there is no active support for these modules. Feel free to ask here on xoops.org tho, you never know if anyone can help you out!

Herko

Thanks Tom, this is because of the new text link ads service. James will fix this issue asap

Herko

PHP 5.2.0 and
MySQL 5.0.27.

At the time these modules were written, these didn't exist. Your problems could very well be caused by too new versions of PHP and MySQL. Why not try downgrade php to the latest 4.x, and see if that works. If the problems persist, why not try downgrading MySQL to the latest 4.x too.

Herko