Martin Dougiamas

Events work fine AFAIK. The only issues might be performance-related if thousands of them land at once.

   http://docs.moodle.org/dev/Events

(Sam might be talking about something else)

Tomasz, I have to say that we had been looking very closely at ousearch already as a replacement for the current search (which will be deleted in 2.2 as it's non-functional and beyond simple fixes).

Happy if you do want to work on something suitable for core but it must be well written and sustainable (unlike the old one). 

One of the things I liked about ousearch is that is stores a lot of required access information in the index, so that you are never shown things you don't have access to.  I think this is a must.

I also liked the fact that things were available to be searched immediately - this is expected these days.

Don't care about the actual solution if it satisfies these AND runs without additional server software (PHP only).

OK, I'm very interested in this whole issue, particularly as I want our core team focussing heavily on usability and interface in 2.3 and 2.4.

The main reason I'm looking at jQuery at all is because every single developer that walks in here for an interview has already used it.   It's more efficient to be working ith a mainstream product (in terms of users).   I think at this point a switch from YUI to jQuery is fairly possible using rosetta stones etc, if we do it soon, although it's a lot of work for core and contrib devs.

I don't understand how we can be library agnostic in a practical way.  Are you saying that every developer can just pick whatever library they want, and we will just load more and more per page?  Won't this kill efficiency?   How will developers communicate effectively and share code and review each others code?   Can you explain this?

My opinion on this is:

A1) All the rubric criteria should be explicitly required. If anyone wants to allow a "0" then they can explicitly include a "0" value in the scale for that criteria.  If they don't, then don't.  Moodle won't need to care or do any guessing.

A2) Yes, I think it's going to be common that faults in rubrics will be discovered after grading is started, and teachers must be allowed to fix the rubric.  We can warn the teacher about the effects and use a "dirty" flag to indicate which graded items need to be checked afterwards.

What you describe could be nice but will also complicate everything quite a bit.

I don't see that we should spend too much effort trying to duplicate what git already does very well (especially when we still have work to do on the basic system as it is). 

If people want to use bleeding-edge alpha code then they will probably want to update quite often.  So why not just give them directions for installing direct from your git repository (eg http://docs.moodle.org/20/en/Git_for_Administrators#Installing_a_contributed_extension_from_its_Git_repository) and make their life easier?