Wedge

Another plus if after 1.x ships, it is in an open[1] repo it might garner other maintainers interest. While that could happen while its still in core as a plug in it might be a good testing/proofing groun for future developers of the project.[2]

Anyway that is my +1 to the idea, I think its a great short term and long term exercise for plug-ins and the project as a whole. Hell it could lead[3] a more module system as a whole down the road.

1.	Open as in people can ask for access maybe even make branches to be merged back and all that fun stuff
2.	Who Join you
3.	loooong term

Why does it have to be an open repo for other people to contribute? All it needs is *active* maintainers and people contributing - the mechanics of it do not require it to be open. In SMF's case, I was contributing bug fixes 8-9 months before they were taken into the core, for example - and their repo isn't open (nor was it at the time), but it didn't prevent me contributing. The blockage was not a lack of openness, but a lack of active maintainers looking at supplied patches and implementing them or rejecting them.

I also doubt that we'll add too many core developers to the project.

Why would it be so bad if people could pull from a repo instead of having to download the source :/ Repo or not the point is the same. I know its a sore subject however I am not one of "them" so I wasn't trying to open any wounds.

You're asking me why it would be so bad to have an open repo - tell me then, why would it be so good if people could pull from a repo instead of having to download the source? Having a milestone release means waypoints for support, for version control etc.

People using SVN versions, except under limited cases, invariably makes the problem so much worse from any real practical perspective, at least in my experience.

Once you have a stable release people should use that branch, all other modifications (besides maybe minor bug fixes) should go into there own branches only to be merged at final release.

Sure people can post patches/fixes/whatever to your tracker and some will, however for even the slightly dedicated it would be better to have them post to branches that you can review and merge back if you accept the fix. I know in Git or Monotone its very simple to grant different levels of permissions ect and to merge back and forth.

Sadly impractical. It would force never backporting fixes to stable branches, amongst other things, because otherwise you'll have some people using 'the stable branch', and some people using 'the stable branch plus some fixes', and it doesn't solve anything, you actually risk fragmenting things worse.

At least with milestone releases, you can locate issues by version. (It's hard enough to get people to actually say what version they have. Very often people can't even get that right. I shudder to imagine them trying to post by revision; at least SVN has revision numbers - Github doesn't last I saw.)Aside from the small fact that trying to merge the disparate branches would be an absolute nightmare. SMF from whence we came, has a very complex nature of inter-dependence. You can't change one thing without having it spread out throughout. Invariably a bug fix requires changes in more than one place, making it rather difficult to actually do this, especially while new things are being coded around it.

If the code were more modular, perhaps it would be feasible, but certainly not the way it is right now.

Thing is, you haven't convinced me why it would be good to open up the repo, you've just told me how I'd use the result, not why it would be good for me, or for Wedge for that matter. I'm happy to review bug fixes and so on, but I'll be absolutely damned if I accept patches in a manner consistent with Github, where someone creates what amounts to a fork branch, commits their changes and magically expects me to commit it. It promotes the expectation that work will be accepted, even when it really won't.

The number of commits accepted from other people thus far is still in single digits. I do not expect that to change as a trend, because we are very protective of our work thus far, and the culture engendered by Github et al, whereby changes are committed into a repo that makes it 'trivial' to incorporate change is actually in my mind a very bad idea. It makes people complacent about including changes, rather than reviewing and putting in the effort to include it.

You see, in all my experience of development, the actually successful projects survive and thrive because they have a specific culture. They have a culture that is a fusion of a meritocracy and a benevolent dictatorship. In other words, people at the top that make the decisions, and people tend to have their opinion listened to more thoroughly if they've proven that they aren't wasting time/effort. If someone consistently posts poor code, I'm not exactly going to be enthusiastic about accepting their bug fixes, now, am I? Yet, social coding explicitly encourages contribution, but it doesn't encourage *good* contribution.

Putting it in the forum is actually a much better barometer for the quality of something in my experience.

Also, see http://wedge.org/pub/off/6923/plugin-development/ which in hindsight is probably a better place for this discussion because we're now so far off topic from what I hoped to discuss...

I don't think it really matters, there's been enough people that have misunderstood the point of what I'm getting at here judging by some of the responses here, not to mention some of the private responses I've had, that I'm actually inclined to leave it in despite my gut instinct.[1]

1.	I've been wrong before about bundling/unbundling features. It makes me wary to consider it much these days.

Not sure if i may post here but...

I just wanted to share with you my "solution" for calendar (or better, for event management). I've disabled the calendar in SMF because in fact it slows my forum (quite sensible differences). But I still need a way to let users insert their events.

So, I've setted up a hidden board (I've created a public child board on a private board, so the index doesn't shwo that board), and a user can insert a topic only by using the custom form (I use a smf mod to do that). So the board has a lot of new topics and the first post is always formatted as you can see here:

http://forum.artistimarziali.org/index.php?topic=9474.0

then, there is a cron job (it runs every hour) that reads all first posts in that board and creates some text files:

• A json file with an ordered array of all events.
• A textfile with the IDs of all expired events.
• A list of files, numbered from 1.html to nnn.html (where nnn is the max board ID)

The first file is used by a home script that reads all events and shows them through that interface:
http://home.artistimarziali.org/?page=eventi

The second file is used by another cron job (that runs every day), to remove old topics.

The rest of files are read by the board template. If you load, for example, the board 33:
http://forum.artistimarziali.org/index.php?board=33.0
the template includes the file 33.html, and shows it at the top of the board list, with the upcoming events.

I know, the system is not the best design but... It's very fast. And I only use a particular board, I've not implemented other tables. :)

It's fast because it's essentially pre-cached. Most of the reason the calendar is slow is because it's not cached and is thus queried every page.

That, and the fact it does other stuff as well in a variety of ways...


Anyway, that's not really why I'm posting. Today's question regarding the calendar is regarding birthdays. I'd typically want to set up birthdays separately to the calendar, so I'm thinking I'd rather separate them out entirely, which means a new question as to plugins.

Specifically, let's assume the calendar is going to be a plugin. Should the whole support for birthdays be made a plugin too? (Note: even if I did pull birthdays support into a plugin, I wouldn't remove age/DOB from the forum, because it has other uses that are core, like COPPA type support)

I think that birthday support has to be plugin too, maybe a part of the calendar plugin (but available as option).

The only important thing, imho, is that the DOB field has to be part of the default forum profile fieldset. :)

Yup, as stated I had no intention of removing that.Yes, that's... um... exactly what I'm trying to get at. There's three routes I can take.

* Make birthdays core and calendar a plugin.
* Make birthdays part of the calendar plugin.
* Make birthdays its own plugin.

I'm trying to gauge which is the best route.

re: Birthdays. If your going modular with calendar, I say make birthdays core, but have it send birthdays to the calendar if you've got calendar installed and enabled.

Isn't that the opposite of modularisation? :P

Well, yes, but... I also consider the birthdays code to be a must have (saves me having to post in our birthdays thread :))

Ah, see, I consider it less of a must-have. But at the same time I'd bring all its functionality together instead of it being disparate as it is now. It would also force me to make sure there is a piece of functionality in the plugin manager that I'd conceived of but not yet implemented.

I'd also likely integrate the other things that are desirable (like the birthday post mod JBlaze and I did).

Thing is, I'd personally rather have birthdays as a plugin on its own rather than being tied explicitly to the calendar; I don't want it on every forum that I run, but where I do, I want it without the calendar - though that is just me.