30 Jan
2014
30 Jan
'14
3:49 p.m.
On 01/30/2014 03:08 PM, vincent(a)massol.net wrote:
[...]
Second one. Yes, I meant about testing and updating the extensions itself.
Of course this will not apply to each and every extension that someone ever uploaded and
then walked away.
Figuring out the "right" extensions by rational criteria would be tricky; maybe
an approach based on personal likes might still produce usable results (i.e.
"attractive" extensions will be maintained).
Instead of a rating system (i.e. how good does the extension work at all) I rather meant a
compatibility label to tell that the extension does not longer work with version x.y
Also I felt it is more constructive to fix a broken extension (assuming it only broke
because of some compatibility issues), and label it as "works with version x.y"
instead of just testing it and label it as "broken with x.y"
On 01/30/2014 10:37 AM, Ecaterina Moraru (Valica) wrote:
I’m not against it, it’s just that I don’t see what there would be to do and I don’t
think there’s enough for everyone. At best you can run this once and it’s over in half a
day. Personally I’m doing this almost every day already…
Or do you mean that this day would be about *testing* all extensions and grade them as
working/not working/etc? If so we would need the ratings system in place on e.x.o first
IMO because we’ll need some way to record what we find.
So you’d need to specify more precisely what this day would be made of I think.
G.1) Improvements issues closing day
I agree this would be important, too. Especially with user interfaces often a
"small" improvement helps a lot improving user experience.
G.4) e.x.o cleaning day (marking old extensions
as deprecated, writing
documentation, specifying what version the extension is working on, etc. )
On 01/30/2014 10:40 AM, vincent(a)massol.net wrote:
This one could be part of the Documentation
Fixing Day IMO.
Unless if one finds out that an extension does not longer work and instead of making it
as deprecated just fixes it.
I feel allocation some time to keep extensions up to date and running would be a good
thing, because:
* most people who start developing code for XWiki start with getting some extension /
code snippet etc. and tweak the a little
* the code they see there are thus the one that gives them the first impression "how
to do things" - if that is outdated code
e.g. using deprecated API, this will cause that kind of "old" code to spread
around in the user base
* if at least some selected part is marked as "up to date" this also gives
users who install extensions a better impression about XWiki in general
* and aside of that, unlike fixing core bugs, updating extensions is something that even
I feel I can do without having my head spin too much. ;)
The only downside I see with that is that folks might prefer to update code, however
remotely useful, to update the documentation ;)
Just for that reason it maybe might be better to distinguish between "xwiki.org Doc
fixing" and "extensions cleaning" day. Thanks
-Vincent
>> The only constraint for defining a day is that it contains small elements that
can be fixed quickly which is the case for the proposals listed above.
>>
>>
>> So what I propose to be precise:
>> - one week out of 2 we do a BFD
>> - the other week we do one of each (A through F). Then once we’ve done a full
round we decide which ones are the best for the project, which ones we want to drop and
which ones we want to repeat more often than others.
>>
>> I also propose that the 6th and 13th we still do a BFD and on the 20th of Feb we
start doing A, then BFD, then B, etc.
>>
>> WDYT? Any other proposal or better idea?
>>
>> Thanks
>> -Vincent
>>