Re: [Wikitech-l] Mailman archives broken?

[Guillaume Paumier]

Hi,

On Thu, Aug 16, 2012 at 7:07 PM, Daniel Zahn  wrote:
>
> the last time we had to rebuild archives was about 2 weeks ago.
> Unfortunately this is a major drawback of removing messages from
> archives as you pointed out and we are aware of it. We had a thread
> there though that contained private information and we also did not
> want to refuse the request of the person affected to remove their
> data. A subsequent request that followed shortly after was actually
> rejected for this very reason. In the future such requests will more
> likely rejected and if unavoidable we will just XXX out information
> instead of removing complete threads to avoid this from happening
> again. Everybody on this list please be extra careful about posting
> private information to a public list you might regret in the future.
> Sorry for breaking links, we are aware URLs should never change if at
> all possible.

Thank you for the explanation, Daniel.

-- 
Guillaume Paumier

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can we make an acceptable behavior policy? (was: Re: Mailman archives broken?)

[Tyler Romeo]

This is (hopefully) a community. When somebody fucks something up, they own
up to it and somebody fixes it (sometimes the person who did it fixes it,
sometimes somebody else). The proper way to phrase it would have been "So
how can we go about fixing this?". By saying that you're not putting one
person on the spot.

As far as an acceptable policy, how about just don't be a
dick
?

*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com



On Thu, Aug 16, 2012 at 10:26 PM, Brandon Harris wrote:

>
> On Aug 16, 2012, at 7:18 PM, MZMcBride  wrote:
>
> > Ryan Lane wrote:
> >>> What is your plan to clean up the mess you made?
> >>
> >> I need to call you out on this MZ. This is an incredibly rude way to
> >> phrase this.
> >>
> >> I get that our community tends to accept this kind of behavior, but I
> >> think we should really put effort into coming up with some method of
> >> discouraging people from acting this way.
> >
> > What would have been a politer way to phrase the question? I originally
> > wrote "when are you going to clean up the mess you made?", but I rewrote
> it.
>
>
> "the mess you made".
>
> Right there, in that phrase, you have aggressively indicated the
> following:
>
> a) That you believe someone fucked up;
> b) That you think they're incompetent;
> c) That you think they're being lazy about it
>
> None of that is helpful.
>
> This communication style typically causes the exact opposite
> response from what you apparently want to have happen.  I can't speak for
> others, but when someone talks to *me* this way, I start tuning them out.
>
> Honey = flies.
>
> ---
> Brandon Harris, Senior Designer, Wikimedia Foundation
>
> Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can we make an acceptable behavior policy? (was: Re: Mailman archives broken?)

[Brandon Harris]

On Aug 16, 2012, at 7:18 PM, MZMcBride  wrote:

> Ryan Lane wrote:
>>> What is your plan to clean up the mess you made?
>> 
>> I need to call you out on this MZ. This is an incredibly rude way to
>> phrase this.
>> 
>> I get that our community tends to accept this kind of behavior, but I
>> think we should really put effort into coming up with some method of
>> discouraging people from acting this way.
> 
> What would have been a politer way to phrase the question? I originally
> wrote "when are you going to clean up the mess you made?", but I rewrote it.


"the mess you made".

Right there, in that phrase, you have aggressively indicated the 
following:

a) That you believe someone fucked up;
b) That you think they're incompetent;
c) That you think they're being lazy about it

None of that is helpful.

This communication style typically causes the exact opposite response 
from what you apparently want to have happen.  I can't speak for others, but 
when someone talks to *me* this way, I start tuning them out. 

Honey = flies.  

---
Brandon Harris, Senior Designer, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can we make an acceptable behavior policy? (was: Re: Mailman archives broken?)

[MZMcBride]

Ryan Lane wrote:
>> What is your plan to clean up the mess you made?
> 
> I need to call you out on this MZ. This is an incredibly rude way to
> phrase this.
> 
> I get that our community tends to accept this kind of behavior, but I
> think we should really put effort into coming up with some method of
> discouraging people from acting this way.

What would have been a politer way to phrase the question? I originally
wrote "when are you going to clean up the mess you made?", but I rewrote it.

The answer can be as simple as "apologize and move on." It's a little
unclear to me what the extent of the damage is, but I don't think it's
unreasonable if someone actively breaks something to expect them to deal
with (or at least mitigate) the consequences, particularly if it's within
their power to do so. I hit this issue at
 before it
was mentioned on the mailing list. I read Daniel's reply as "shit happens"
(which is a perfectly acceptable response sometimes). But given the open
editing nature of the sites primarily affected and the fact that the sites
track external link usage, I'm not sure it's out-of-line to suggest that the
person (or people) who made the mess of the links clean it up. If it was
out-of-line, I apologize.

Regarding an acceptable behavior policy, what did you have in mind?

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Can we make an acceptable behavior policy? (was: Re: Mailman archives broken?)

[Ryan Lane]

> What is your plan to clean up the mess you made?
>

I need to call you out on this MZ. This is an incredibly rude way to
phrase this.

I get that our community tends to accept this kind of behavior, but I
think we should really put effort into coming up with some method of
discouraging people from acting this way.

- Ryan

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Mailman archives broken?

[MZMcBride]

Daniel Zahn wrote:
> On Thu, Aug 16, 2012 at 1:49 PM, Federico Leva (Nemo)
>  wrote:
>> Thanks Daniel. I don't understand, how can a message need to be removed
>> completely?
> 
> In this case the request was for a complete thread to be removed.
> Since many people reply with full quotes it usually repeats the
> information in almost every message. ("TOFU"-posting). But you are
> right, even in these cases we should, and will, just replace content
> of every message with a "deleted" message.

What is your plan to clean up the mess you made?

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Smart machine-learning based anti-spam system (I wish!)

[Tim Starling]

On 17/08/12 04:16, Daniel Friesen wrote:
> Of course. While I have the whole idea for the ui, backend stuff, how
> to handle the service, etc... I haven't done the actual
> machine-learning stuff before.

I would think that the actual machine learning stuff would be the hard
part. I stopped using Thunderbird's Bayesian spam tagging feature
years ago, when it started sorting emails from smart people in with
the spam. The computer thought that the smart people were using long
words with a similar frequency to the random dictionary words that
padded out the spam messages.

I haven't worked with machine learning either, but I'm guessing it's
not as simple as feeding a pre-tagged data set into a stock Bayesian
filter library.

-- Tim Starling


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Smart machine-learning based anti-spam system (I wish!)

[Chris Steipp]

Hi Daniel,

A lot of your ideas are covered by
http://en.wikipedia.org/wiki/Wikipedia:STiki. Andrew has done a lot of
great research, if you haven't read his papers yet that might be a
good intro to the type of machine learning approaches that have been
used.

That being said, I would love to have some system that is constantly
learning from the edits that are flagged as spam, that we can query
with new edits from AbuseFilter to get a score of how likely it is
that this new edit is spam. If you get around to working on your
system, it would be great to work out some way to interface.


On Thu, Aug 16, 2012 at 11:16 AM, Daniel Friesen
 wrote:
> I've had a good idea for an anti-spam system for awhile.
> Blocks, Captchas, and local filters, all the tricks we've been using end up
> not working well enough to easily deal with the spam on a lot of wikis.
>
> I know this because I've been continually dealing with the spam on a small
> dead wiki. Simple AntiSpam, AntiBot, Captchas, TorBlock, Abuse Filter...
> Time after time I expand my filters more and more. But inevitably a few days
> later spam not covered by my filters comes through and I have to do it
> again.
>
> I ended up having to deal with it more today and then started writing out
> the details I've had for awhile on a machine-learning based anti-spam
> system.
>
> https://www.mediawiki.org/wiki/User:Dantman/Anti-spam_system
>
> Of course. While I have the whole idea for the ui, backend stuff, how to
> handle the service, etc... I haven't done the actual machine-learning stuff
> before.
> Also naturally just like Gareth, OAuth, and other things this is just
> another one of my ideas I don't have the time and resources to do and wish I
> had the financial backing to work on.
>
> --
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] EtherEditor testing, round 3: Minor stress test

[Mark Holmquist]

So I'm here to ask for some volunteers to help me test EtherEditor
tomorrow, between 20:00 and 22:00 UTC. I'll be in #ethereditor on
Freenode with a list of things to try out, and really, some number of
people helping me stress test the connections to the backend would be
immensely useful.


All right! A bunch of awesome people showed up to help, and I got a 
bunch of interesting results. I'm sure I'll be back soon to announce a 
more stable release.


Thanks especially to Chris McMahon, Thomas Gries (Wikinaut), S Page, and 
all the others who hopped on to help break my software :)


--
Mark Holmquist
Contractor, Wikimedia Foundation
mtrac...@member.fsf.org
http://marktraceur.info

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Mailman archives broken?

[Daniel Zahn]

On Thu, Aug 16, 2012 at 1:49 PM, Federico Leva (Nemo)
 wrote:
> Thanks Daniel. I don't understand, how can a message need to be removed
> completely?

In this case the request was for a complete thread to be removed.
Since many people reply with full quotes it usually repeats the
information in almost every message. ("TOFU"-posting). But you are
right, even in these cases we should, and will, just replace content
of every message with a "deleted" message.

-- 
Daniel Zahn 
Operations Engineer

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Mailman archives broken?

[Federico Leva (Nemo)]

Thanks Daniel. I don't understand, how can a message need to be removed 
completely? I can't imagine anything which couldn't just be redacted  by 
leaving at least the message's "skeleton" as demanded by 



Nemo

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OAuth Implementation

[Chris Steipp]

Hi Tyler,

I've been slowly trying to organize getting an implementation done.
OAuth does have it's issues, but about once a week I have other
developers here at WMF who want to do a project that would be much
easier and more secure if we had OAuth.

We started a list of stories here
http://www.mediawiki.org/wiki/OAuth/User_stories

And I'm currently trying to recruit developers to help work on it, in
be (not so frequent) spare moments.

It would be great to have some of your help on it!


On Thu, Aug 16, 2012 at 12:41 PM, Tyler Romeo  wrote:
> I indeed meant the OAuth extension for PHP (the PECL one).
>
> *--*
> *Tyler Romeo*
> Stevens Institute of Technology, Class of 2015
> Major in Computer Science
> www.whizkidztech.com | tylerro...@gmail.com
>
>
>
> On Thu, Aug 16, 2012 at 3:41 PM, Derric Atzrott <
> datzr...@alizeepathology.com> wrote:
>
>> >Read both OAuth 2 (and it's Bearer and MAC specs) and the OAuth 1 RFC.
>> >
>> >I would probably avoid reading the PHP code for it. I have a feeling that
>> >it's going to do nothing but give you some wrong ideas about how OAuth
>> >should be implemented.
>>
>> I think he meant the OAuth extension for PHP [0] rather than other people's
>> implementations of OAuth in PHP.
>>
>> Or was that what you meant too?  I've not read the OAuth spec yet (though
>> it
>> is on my reading list).
>>
>> Thank you,
>> Derric Atzrott
>>
>> [0]: http://php.net/manual/en/book.oauth.php
>>
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] EtherEditor stress test about to start

[Mark Holmquist]

A brief note, we're about to start a stress test of EtherEditor, an 
extension for real-time collaborative editing, at 20:00 UTC. If you'd 
like to help out, or if you'd like to watch, do please join us in 
#ethereditor on Freenode. If you don't have IRC for whatever reason, but 
still would like to help out with the project, feel free to email me 
(either on-list or off) or just check out the mediawiki.org page about 
the extension [0].


[0] http://www.mediawiki.org/wiki/Extension:EtherEditor

Thanks!

--
Mark Holmquist
Contractor, Wikimedia Foundation
mtrac...@member.fsf.org
http://marktraceur.info

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OAuth Implementation

[Tyler Romeo]

I indeed meant the OAuth extension for PHP (the PECL one).

*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com



On Thu, Aug 16, 2012 at 3:41 PM, Derric Atzrott <
datzr...@alizeepathology.com> wrote:

> >Read both OAuth 2 (and it's Bearer and MAC specs) and the OAuth 1 RFC.
> >
> >I would probably avoid reading the PHP code for it. I have a feeling that
> >it's going to do nothing but give you some wrong ideas about how OAuth
> >should be implemented.
>
> I think he meant the OAuth extension for PHP [0] rather than other people's
> implementations of OAuth in PHP.
>
> Or was that what you meant too?  I've not read the OAuth spec yet (though
> it
> is on my reading list).
>
> Thank you,
> Derric Atzrott
>
> [0]: http://php.net/manual/en/book.oauth.php
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OAuth Implementation

[Tyler Romeo]

Mhm, sounds good. *sigh* Going to be a long journey.

*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com



On Thu, Aug 16, 2012 at 3:23 PM, Daniel Friesen
wrote:

> Read both OAuth 2 (and it's Bearer and MAC specs) and the OAuth 1 RFC.
>
> I would probably avoid reading the PHP code for it. I have a feeling that
> it's
> going to do nothing but give you some wrong ideas about how OAuth should
> be implemented.
>
>
> --
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
> On Thu, 16 Aug 2012 12:11:05 -0700, Tyler Romeo 
> wrote:
>
>  Yeah I've noticed. I decided to start with reading the OAuth IETF document
>> first so I'm totally familiarized with the protocol. Then I'm going to
>> look
>> at the PHP extension (although in the long run I don't want to have it as
>> a
>> dependency), and finally I'm going to look through the mailing list and
>> other stuff. Then I'll draft some stuff and put it out here for
>> discussion.
>>
>> *--*
>> *Tyler Romeo*
>> Stevens Institute of Technology, Class of 2015
>> Major in Computer Science
>> www.whizkidztech.com | tylerro...@gmail.com
>>
>>
>>
>> On Thu, Aug 16, 2012 at 3:02 PM, Daniel Friesen
>> **wrote:
>>
>>  On Thu, 16 Aug 2012 11:39:54 -0700, Tyler Romeo 
>>> wrote:
>>>
>>>  Is anybody working on OAuth for MediaWiki? Because if not I might put
>>>
 something together (i.e., start putting together design documents based
 on
 http://www.mediawiki.org/wiki/OAuth
 
 >

 ).

 *--*
 *Tyler Romeo*

 Stevens Institute of Technology, Class of 2015
 Major in Computer Science
 www.whizkidztech.com | tylerro...@gmail.com


>>> That OAuth page is actually quite old.
>>>
>>> You should read over all the mailing list and Talk:OAuth topics.
>>> Especially the stuff on writing this type of auth into core as an
>>> abstract
>>> system.
>>> As well please take a good long read over:
>>> https://www.mediawiki.org/wiki/OAuth/Issues
>>> 
>>> >
>>>
>>>
>>> Also note I don't think we've had a real discussion over OAuth yet. The
>>> OAuth discussions I've tried to spark up haven't gone far. And whoever is
>>> in the subgroup here that actually understands OAuth haven't even had a
>>> discussion over it.
>>>
>>> --
>>> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>>>
>>
> __**_
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OAuth Implementation

[Derric Atzrott]

>Read both OAuth 2 (and it's Bearer and MAC specs) and the OAuth 1 RFC.
>
>I would probably avoid reading the PHP code for it. I have a feeling that
>it's going to do nothing but give you some wrong ideas about how OAuth
>should be implemented.

I think he meant the OAuth extension for PHP [0] rather than other people's
implementations of OAuth in PHP.

Or was that what you meant too?  I've not read the OAuth spec yet (though it
is on my reading list).

Thank you,
Derric Atzrott

[0]: http://php.net/manual/en/book.oauth.php


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OAuth Implementation

[Daniel Friesen]

Read both OAuth 2 (and it's Bearer and MAC specs) and the OAuth 1 RFC.

I would probably avoid reading the PHP code for it. I have a feeling that  
it's
going to do nothing but give you some wrong ideas about how OAuth should  
be implemented.


--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

On Thu, 16 Aug 2012 12:11:05 -0700, Tyler Romeo   
wrote:


Yeah I've noticed. I decided to start with reading the OAuth IETF  
document
first so I'm totally familiarized with the protocol. Then I'm going to  
look
at the PHP extension (although in the long run I don't want to have it  
as a

dependency), and finally I'm going to look through the mailing list and
other stuff. Then I'll draft some stuff and put it out here for  
discussion.


*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com



On Thu, Aug 16, 2012 at 3:02 PM, Daniel Friesen
wrote:


On Thu, 16 Aug 2012 11:39:54 -0700, Tyler Romeo 
wrote:

 Is anybody working on OAuth for MediaWiki? Because if not I might put
something together (i.e., start putting together design documents  
based on

http://www.mediawiki.org/wiki/**OAuth
).

*--*
*Tyler Romeo*

Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com



That OAuth page is actually quite old.

You should read over all the mailing list and Talk:OAuth topics.
Especially the stuff on writing this type of auth into core as an  
abstract

system.
As well please take a good long read over:
https://www.mediawiki.org/**wiki/OAuth/Issues

Also note I don't think we've had a real discussion over OAuth yet. The
OAuth discussions I've tried to spark up haven't gone far. And whoever  
is

in the subgroup here that actually understands OAuth haven't even had a
discussion over it.

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OAuth Implementation

[Tyler Romeo]

Yeah I've noticed. I decided to start with reading the OAuth IETF document
first so I'm totally familiarized with the protocol. Then I'm going to look
at the PHP extension (although in the long run I don't want to have it as a
dependency), and finally I'm going to look through the mailing list and
other stuff. Then I'll draft some stuff and put it out here for discussion.

*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com



On Thu, Aug 16, 2012 at 3:02 PM, Daniel Friesen
wrote:

> On Thu, 16 Aug 2012 11:39:54 -0700, Tyler Romeo 
> wrote:
>
>  Is anybody working on OAuth for MediaWiki? Because if not I might put
>> something together (i.e., start putting together design documents based on
>> http://www.mediawiki.org/wiki/**OAuth
>> ).
>>
>> *--*
>> *Tyler Romeo*
>>
>> Stevens Institute of Technology, Class of 2015
>> Major in Computer Science
>> www.whizkidztech.com | tylerro...@gmail.com
>>
>
> That OAuth page is actually quite old.
>
> You should read over all the mailing list and Talk:OAuth topics.
> Especially the stuff on writing this type of auth into core as an abstract
> system.
> As well please take a good long read over:
> https://www.mediawiki.org/**wiki/OAuth/Issues
>
> Also note I don't think we've had a real discussion over OAuth yet. The
> OAuth discussions I've tried to spark up haven't gone far. And whoever is
> in the subgroup here that actually understands OAuth haven't even had a
> discussion over it.
>
> --
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
> __**_
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OAuth Implementation

[Daniel Friesen]

On Thu, 16 Aug 2012 11:39:54 -0700, Tyler Romeo   
wrote:



Is anybody working on OAuth for MediaWiki? Because if not I might put
something together (i.e., start putting together design documents based  
on

http://www.mediawiki.org/wiki/OAuth).

*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com


That OAuth page is actually quite old.

You should read over all the mailing list and Talk:OAuth topics.  
Especially the stuff on writing this type of auth into core as an abstract  
system.

As well please take a good long read over:
https://www.mediawiki.org/wiki/OAuth/Issues

Also note I don't think we've had a real discussion over OAuth yet. The  
OAuth discussions I've tried to spark up haven't gone far. And whoever is  
in the subgroup here that actually understands OAuth haven't even had a  
discussion over it.


--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] OAuth Implementation

[Tyler Romeo]

Is anybody working on OAuth for MediaWiki? Because if not I might put
something together (i.e., start putting together design documents based on
http://www.mediawiki.org/wiki/OAuth).

*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] organize a bug triage

[bawolff]

> Hello,
>
> We didn't have a bug triage since May. I suggest organizing one in a few
> weeks (say 2?)
>
> I agree to take care of this if it is widely supported.
> How about focusing on patch triage?
>
> I mean reviewing bugs with patches attached but not in gerrit.
>
> Any other subject would be good as well.
>
> opinions?
>
> Matanya

I  think this is an excellent idea.

A patch triage sounds like a good idea, especially for a first such
triage after no one doing them in a while. After all even in magical
git land, its still important to respond to bugzilla patches. If this
triage session is successful, I think doing future sessions of
"prioritize and assign the incoming bugs" would also be good


/me just really misses all hexmode's bug spam :)

Re Al Snow
> b. Verify fix
>   * Verifying fixes (STATUS is "RESOLVED"; RESOLUTION is "FIXED")
>
> c. Accept non-fix resolution
>  * Accepting all non-fixed resolution.
>  * STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5 
> non-"FIXED" RESOLUTION values)

I thought that's what Wikipedia was for (joke, but only sort of.
There's enough open bugs in need of love that verifying a RESOLVED
WORKSFORME bug really works for us doesn't seem that useful)

-bawolff

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] organize a bug triage

[Al Snow]

Thanks Chad and Andre for your responses.
I am new to the community and did not know that RESOLVED bugs were considered 
CLOSED. Thanks for the update.

Al Snow

> Date: Thu, 16 Aug 2012 14:01:33 -0400
> From: innocentkil...@gmail.com
> To: wikitech-l@lists.wikimedia.org
> Subject: Re: [Wikitech-l] organize a bug triage
> 
> Triaging already closed bugs seems like a huge waste of time when there's
> so many open bugs that need love.
> 
> -Chad
> On Aug 16, 2012 1:53 PM, "Andre Klapper"  wrote:
> 
> > Hi Al,
> >
> > [Expectations, workflows and manpower among FOSS projects differ so
> > please take my comments with a grain of salt as I don't follow the
> > Wikimedia project that closely.]
> >
> > On Thu, 2012-08-16 at 13:31 -0400, Al Snow wrote:
> > > > > c. Accept non-fix resolution
> > > > > * Accepting all non-fixed resolution.
> > > > > * STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5
> > non-"FIXED" RESOLUTION values)
> > >
> > > > Sorry but I don't know what you mean by "accepting" here. :/
> > > When I look at the non-"FIXED" RESOLUTIONs that I know about (INVALID,
> > > WONTFIX, LATER, DUPLICATE, and WORKSFORME), the next step is to REOPEN
> > > it or accept the resolution and change status to VERIFIED.
> >
> > ...or to just leave a report as it is? :)
> >
> > REOPENing normally happens if the reporter, developer or another party
> > interested in fixing the issue realizes that a committed fix did not fix
> > the issue, or to signal disagreement. I'm not convinced if triagers can
> > help here to save any of those persons some time.
> >
> > Also I don't really see who it helps to verify RESOLVED DUPLICATE.
> > Personally I rather consider it a waste of time (anybody is free to
> > disagree of course) as efforts are better spent on general triaging like
> > identifying duplicates etc. which seems to be a bigger help for users
> > and developers.
> >
> > For the other four options I normally leave it to the reporter. For
> > example verifying a WONTFIX (=stating for a second time that the request
> > will not receive a fix) might make a reporter feel less acknowledged for
> > spending time on reporting a bug or request.
> >
> > andre
> >
> > PS: For anybody _really_ interested in discussing the use of the
> > VERIFIED status in Bugzilla I recommend a recent thread on the Mozilla
> > dev-platform/dev-quality mailing lists at
> >
> > https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/gn9SC8wQ4sA[1-25]
> >
> > --
> > Andre Klapper (maemo.org bugmaster & GNOME Bugsquad)
> > http://blogs.gnome.org/aklapper/


  
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Smart machine-learning based anti-spam system (I wish!)

[Daniel Friesen]

I've had a good idea for an anti-spam system for awhile.
Blocks, Captchas, and local filters, all the tricks we've been using end  
up not working well enough to easily deal with the spam on a lot of wikis.


I know this because I've been continually dealing with the spam on a small  
dead wiki. Simple AntiSpam, AntiBot, Captchas, TorBlock, Abuse Filter...
Time after time I expand my filters more and more. But inevitably a few  
days later spam not covered by my filters comes through and I have to do  
it again.


I ended up having to deal with it more today and then started writing out  
the details I've had for awhile on a machine-learning based anti-spam  
system.


https://www.mediawiki.org/wiki/User:Dantman/Anti-spam_system

Of course. While I have the whole idea for the ui, backend stuff, how to  
handle the service, etc... I haven't done the actual machine-learning  
stuff before.
Also naturally just like Gareth, OAuth, and other things this is just  
another one of my ideas I don't have the time and resources to do and wish  
I had the financial backing to work on.


--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] organize a bug triage

[Chad]

Triaging already closed bugs seems like a huge waste of time when there's
so many open bugs that need love.

-Chad
On Aug 16, 2012 1:53 PM, "Andre Klapper"  wrote:

> Hi Al,
>
> [Expectations, workflows and manpower among FOSS projects differ so
> please take my comments with a grain of salt as I don't follow the
> Wikimedia project that closely.]
>
> On Thu, 2012-08-16 at 13:31 -0400, Al Snow wrote:
> > > > c. Accept non-fix resolution
> > > > * Accepting all non-fixed resolution.
> > > > * STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5
> non-"FIXED" RESOLUTION values)
> >
> > > Sorry but I don't know what you mean by "accepting" here. :/
> > When I look at the non-"FIXED" RESOLUTIONs that I know about (INVALID,
> > WONTFIX, LATER, DUPLICATE, and WORKSFORME), the next step is to REOPEN
> > it or accept the resolution and change status to VERIFIED.
>
> ...or to just leave a report as it is? :)
>
> REOPENing normally happens if the reporter, developer or another party
> interested in fixing the issue realizes that a committed fix did not fix
> the issue, or to signal disagreement. I'm not convinced if triagers can
> help here to save any of those persons some time.
>
> Also I don't really see who it helps to verify RESOLVED DUPLICATE.
> Personally I rather consider it a waste of time (anybody is free to
> disagree of course) as efforts are better spent on general triaging like
> identifying duplicates etc. which seems to be a bigger help for users
> and developers.
>
> For the other four options I normally leave it to the reporter. For
> example verifying a WONTFIX (=stating for a second time that the request
> will not receive a fix) might make a reporter feel less acknowledged for
> spending time on reporting a bug or request.
>
> andre
>
> PS: For anybody _really_ interested in discussing the use of the
> VERIFIED status in Bugzilla I recommend a recent thread on the Mozilla
> dev-platform/dev-quality mailing lists at
>
> https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/gn9SC8wQ4sA[1-25]
>
> --
> Andre Klapper (maemo.org bugmaster & GNOME Bugsquad)
> http://blogs.gnome.org/aklapper/
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] organize a bug triage

[Andre Klapper]

Hi Al,

[Expectations, workflows and manpower among FOSS projects differ so
please take my comments with a grain of salt as I don't follow the
Wikimedia project that closely.]

On Thu, 2012-08-16 at 13:31 -0400, Al Snow wrote:
> > > c. Accept non-fix resolution
> > > * Accepting all non-fixed resolution.
> > > * STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5 
> > > non-"FIXED" RESOLUTION values)
> 
> > Sorry but I don't know what you mean by "accepting" here. :/
> When I look at the non-"FIXED" RESOLUTIONs that I know about (INVALID,
> WONTFIX, LATER, DUPLICATE, and WORKSFORME), the next step is to REOPEN
> it or accept the resolution and change status to VERIFIED.

...or to just leave a report as it is? :)

REOPENing normally happens if the reporter, developer or another party
interested in fixing the issue realizes that a committed fix did not fix
the issue, or to signal disagreement. I'm not convinced if triagers can
help here to save any of those persons some time.

Also I don't really see who it helps to verify RESOLVED DUPLICATE.
Personally I rather consider it a waste of time (anybody is free to
disagree of course) as efforts are better spent on general triaging like
identifying duplicates etc. which seems to be a bigger help for users
and developers.

For the other four options I normally leave it to the reporter. For
example verifying a WONTFIX (=stating for a second time that the request
will not receive a fix) might make a reporter feel less acknowledged for
spending time on reporting a bug or request.

andre

PS: For anybody _really_ interested in discussing the use of the
VERIFIED status in Bugzilla I recommend a recent thread on the Mozilla
dev-platform/dev-quality mailing lists at 
https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/gn9SC8wQ4sA[1-25]

-- 
Andre Klapper (maemo.org bugmaster & GNOME Bugsquad)
http://blogs.gnome.org/aklapper/


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] organize a bug triage

[Al Snow]

Andre,
> > c. Accept non-fix resolution
> > * Accepting all non-fixed resolution.
> > * STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5 
> > non-"FIXED" RESOLUTION values)

> Sorry but I don't know what you mean by "accepting" here. :/
When I look at the non-"FIXED" RESOLUTIONs that I know about (INVALID, WONTFIX, 
LATER, DUPLICATE, and WORKSFORME), the next step is to REOPEN it or accept the 
resolution and change status to VERIFIED.
Here is a chart with these RESOLUTIONS: 
https://bugzilla.wikimedia.org/reports.cgi?product=Wikimedia&banner=1&datasets=INVALID&datasets=WONTFIX&datasets=LATER&datasets=DUPLICATE&datasets=WORKSFORME

Thanks for the question,
Al Snow

> From: andre_klap...@gmx.net
> To: wikitech-l@lists.wikimedia.org
> Date: Thu, 16 Aug 2012 19:21:12 +0200
> Subject: Re: [Wikitech-l] organize a bug triage
> 
> Hi Al,
> 
> On Thu, 2012-08-16 at 11:02 -0400, Al Snow wrote:
> > I see 3 types of bug triages:
> 
> Thanks. These could be added to
> https://www.mediawiki.org/wiki/Project:WikiProject_Bug_Squad/Activities
> 
> Some more ideas could be to concentrate on a single module (e.g.
> extensions) or to update/try to reproduce issues that were reported for
> old versions and have not seen changes for a while (in Bugzilla's
> query.cgi under "Search By Change History" you can replace "Now" by e.g.
> "-731d" to get all tickets without any changes for the last two years).
> Or to update/retest the reports that you filed yourself, or.
> 
> >  a. Up-front
> >   * Confirming bugs and assigning them to developers.
> >   * STATUS is "UNCONFIRMED", "NEW", "REOPENED"; RESOLUTION is N/A
> 
> I'd say that this normally requires knowledge which developers work on
> what. To me that makes it a harder task for "newbies" and might require
> people that have been in the community for quite a while.
> Just trying to clarify potential prerequisites.
> 
> >  b. Verify fix
> > * Verifying fixes (STATUS is "RESOLVED"; RESOLUTION is "FIXED")
> 
> At least for more recent fixes this might require running (potentially
> unstable) code from latest git master instead of a (stable) tarball?
> Somebody please correct me if I'm wrong. 
> Again, just potential prerequisites.
> 
> >  c. Accept non-fix resolution
> >   * Accepting all non-fixed resolution.
> >   * STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5 
> > non-"FIXED" RESOLUTION values)
> 
> Sorry but I don't know what you mean by "accepting" here. :/
> 
> @matanya et al: 
> I'd highly appreciate if you could try to document how to organize a
> bugday for future organizers (e.g. announcement, potential problems),
> and maybe alongside update (or identify gaps in) the Triage Guide at
> https://www.mediawiki.org/wiki/Bug_management/How_to_triage whenever
> needed. (But that guide is rather incomplete currently anyway.)
> 
> Thanks,
> andre
> -- 
> Andre Klapper (maemo.org bugmaster & GNOME Bugsquad)
> http://blogs.gnome.org/aklapper/
> 
> 
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] organize a bug triage

[Andre Klapper]

Hi Al,

On Thu, 2012-08-16 at 11:02 -0400, Al Snow wrote:
> I see 3 types of bug triages:

Thanks. These could be added to
https://www.mediawiki.org/wiki/Project:WikiProject_Bug_Squad/Activities

Some more ideas could be to concentrate on a single module (e.g.
extensions) or to update/try to reproduce issues that were reported for
old versions and have not seen changes for a while (in Bugzilla's
query.cgi under "Search By Change History" you can replace "Now" by e.g.
"-731d" to get all tickets without any changes for the last two years).
Or to update/retest the reports that you filed yourself, or.

>  a. Up-front
>   * Confirming bugs and assigning them to developers.
>   * STATUS is "UNCONFIRMED", "NEW", "REOPENED"; RESOLUTION is N/A

I'd say that this normally requires knowledge which developers work on
what. To me that makes it a harder task for "newbies" and might require
people that have been in the community for quite a while.
Just trying to clarify potential prerequisites.

>  b. Verify fix
> * Verifying fixes (STATUS is "RESOLVED"; RESOLUTION is "FIXED")

At least for more recent fixes this might require running (potentially
unstable) code from latest git master instead of a (stable) tarball?
Somebody please correct me if I'm wrong. 
Again, just potential prerequisites.

>  c. Accept non-fix resolution
>   * Accepting all non-fixed resolution.
>   * STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5 
> non-"FIXED" RESOLUTION values)

Sorry but I don't know what you mean by "accepting" here. :/

@matanya et al: 
I'd highly appreciate if you could try to document how to organize a
bugday for future organizers (e.g. announcement, potential problems),
and maybe alongside update (or identify gaps in) the Triage Guide at
https://www.mediawiki.org/wiki/Bug_management/How_to_triage whenever
needed. (But that guide is rather incomplete currently anyway.)

Thanks,
andre
-- 
Andre Klapper (maemo.org bugmaster & GNOME Bugsquad)
http://blogs.gnome.org/aklapper/


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Mailman archives broken?

[Daniel Zahn]

On Thu, Aug 16, 2012 at 2:00 AM, Guillaume Paumier
 wrote:

> I was told yesterday that the mailman/pipermail archives were broken,
> in that permalinks were no longer linking to the messages they used to
> link to (therefore not being "permalinks" at all).\

Hi Guillaume,

the last time we had to rebuild archives was about 2 weeks ago.
Unfortunately this is a major drawback of removing messages from
archives as you pointed out and we are aware of it. We had a thread
there though that contained private information and we also did not
want to refuse the request of the person affected to remove their
data. A subsequent request that followed shortly after was actually
rejected for this very reason. In the future such requests will more
likely rejected and if unavoidable we will just XXX out information
instead of removing complete threads to avoid this from happening
again. Everybody on this list please be extra careful about posting
private information to a public list you might regret in the future.
Sorry for breaking links, we are aware URLs should never change if at
all possible.

reference ticket is RT-3281

-- 
Daniel Zahn 
Operations Engineer

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] organize a bug triage

[Al Snow]

I see 3 types of bug triages:

 a. Up-front
  * Confirming bugs and assigning them to developers.
  * STATUS is "UNCONFIRMED", "NEW", "REOPENED"; RESOLUTION is N/A

 b. Verify fix
* Verifying fixes (STATUS is "RESOLVED"; RESOLUTION is "FIXED")

 c. Accept non-fix resolution
  * Accepting all non-fixed resolution.
  * STATUS is RESOLVED; RESOLUTION is not "FIXED" (I count at least 5 
non-"FIXED" RESOLUTION values)

Here is a Wikimedia bug table report: 
https://bugzilla.wikimedia.org/report.cgi?y_axis_field=product&x_axis_field=bug_status&z_axis_field=&query_format=report-table&format=table&action=wrapNote
 the different format at the bottom of the web page.
Hope this helps,Al Snow
###

Date: Thu, 16 Aug 2012 16:17:15 +0300
From: mata...@moses.co.il
To: wikitech-l@lists.wikimedia.org
Subject: [Wikitech-l] organize a bug triage

Hello,
 
We didn't have a bug triage since May. I suggest organizing one in a few
weeks (say 2?)
 
I agree to take care of this if it is widely supported.
How about focusing on patch triage?
 
I mean reviewing bugs with patches attached but not in gerrit.
 
Any other subject would be good as well.
 
opinions?
 
Matanya
 

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l 
  
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Wikidata weekly blocker mail

[Denny Vrandečić]

Hi all,

no new blockers.

The two current blockers are still open, and the discussion is
ongoing. In both cases the ball in our court right now:

* The Wikidata branch
(https://bugzilla.wikimedia.org/show_bug.cgi?id=38622): the latest
comment by Tim 
needs to be addressed by us. It is currently for a few days on hold
internally, as Daniel K. is on vacations. He plans to work on it first
thing next week.

* The Sites table
(https://bugzilla.wikimedia.org/show_bug.cgi?id=38705): a discussion
has started here, leading to a few open questions for us to answer and
an RFC to join. We plan to get to this very fast (I am writing that
mail for two days now, and cannot find enough time to finish it). I
can only point everyone who wants to join to the RFC and to add their
use cases to it:

From the collected use cases at the RFC, we want to draft a solution
that is most advantageous for MediaWiki as a whole, and then see how
we can fit our current needs into it.

We are working on both. Thanks to everyone who joined and helped so far!

Cheers,
Denny

-- 
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] organize a bug triage

[matanya]

Hello,

We didn't have a bug triage since May. I suggest organizing one in a few
weeks (say 2?)

I agree to take care of this if it is widely supported.
How about focusing on patch triage?

I mean reviewing bugs with patches attached but not in gerrit.

Any other subject would be good as well.

opinions?

Matanya



signature.asc
Description: OpenPGP digital signature
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Notification bubble system

[Daniel Friesen]

I didn't like jsMessage's behaviour of mw.util.jsMessage( 'Foo' );
treating 'Foo' as html, so any string you pass will be treated as plaintext.
But it does accept arbitrary DOM nodes and jQuery objects just like
jsMessage did. And as a bonus it will also accept a mw.message instance
and automatically call .parse() on it to get the html.
If you have a raw html string just use jQuery's $.parseHTML.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

On 12-08-16 3:01 AM, Andrew Garrett wrote:
> This looks like it would work brilliantly for Echo real time
> notifications. Does it accept arbitrary HTML as a payload?
>
> On Mon, Aug 13, 2012 at 6:18 PM, Daniel Friesen
> mailto:li...@nadir-seen-fire.com>> wrote:
>
> A little while ago Trevor Parscal changed our jsMessage setup to
> be a floating auto-hiding notification bubble.
> https://gerrit.wikimedia.org/r/#/c/17605/
>
> The end implementation felt half-baked to me. Since it just
> swapped text for notification replacement. And didn't support
> multiple notifications. It even reused the same id as the previous
> message which was pretty much a completely different concept.
>
> So I spent a night implementing a fully featured notification
> bubble system. Something that should work for watchlists,
> VisualEditor, and perhaps some other things like LQT, and perhaps
> anything we want to start making more dynamic. Same goes for
> anyone with a good Gadget idea that could use better notifications.
>
> Here's a demo video of the new notification system:
> https://www.mediawiki.org/wiki/File:Mw-notification.ogv
>
>
> The changeset is https://gerrit.wikimedia.org/r/#/c/19199/
>
> -- 
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire)
> [http://daniel.friesen.name]
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org 
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
>
> -- 
> Andrew Garrett
> Wikimedia Foundation
> agarr...@wikimedia.org 


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Notification bubble system

[Andrew Garrett]

This looks like it would work brilliantly for Echo real time notifications.
Does it accept arbitrary HTML as a payload?

On Mon, Aug 13, 2012 at 6:18 PM, Daniel Friesen
wrote:

> A little while ago Trevor Parscal changed our jsMessage setup to be a
> floating auto-hiding notification bubble.
> https://gerrit.wikimedia.org/**r/#/c/17605/
>
> The end implementation felt half-baked to me. Since it just swapped text
> for notification replacement. And didn't support multiple notifications. It
> even reused the same id as the previous message which was pretty much a
> completely different concept.
>
> So I spent a night implementing a fully featured notification bubble
> system. Something that should work for watchlists, VisualEditor, and
> perhaps some other things like LQT, and perhaps anything we want to start
> making more dynamic. Same goes for anyone with a good Gadget idea that
> could use better notifications.
>
> Here's a demo video of the new notification system:
> https://www.mediawiki.org/**wiki/File:Mw-notification.ogv
>
>
> The changeset is 
> https://gerrit.wikimedia.org/**r/#/c/19199/
>
> --
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
> __**_
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
>



-- 
Andrew Garrett
Wikimedia Foundation
agarr...@wikimedia.org
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Mailman archives broken?

[Guillaume Paumier]

Hi,

I was told yesterday that the mailman/pipermail archives were broken,
in that permalinks were no longer linking to the messages they used to
link to (therefore not being "permalinks" at all).

I know this happened at least once in the past, when the archives were
rebuilt. Retroactively fixing permalinks on-wiki and elsewhere is a
nightmare (particularly for old messages used to source early
Wikimedia history), and we're still finding tons of obsolete links
today. I'm hoping that whatever caused the permalinks to be changed
again can be swiftly reverted, so that we don't end up with another
huge pile of obsolete links.

Does anyone have any more information about what happened this time,
and if there's any chance links will be returned to their previous
state? I haven't been able to find a thread or recent bug about this
issue.

Thanks,

-- 
Guillaume Paumier

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit evaluation: where we stand

[Oren Bochman]

>That said there are known negatives; the Java+Google Web Toolkit >front-end
is intimidating to people who might want to help improve >the UI; even
Gerrit devs don't love it. :)

>Improvements to the UI and to the git-review CLI tool are welcome...

Intimidating to PHP+JS only devs - but Java+Google Web Toolkit is this
systems second iteration for Gerrit. I think that it would be possible to
add all the changes we need into Gerrit, I personally feel more comfortable
hacking Gerrit which has an upstream and a community than our previous code
review plug-in which had none. A large number of our issues are already
being added by the Gerrit community and by Chad. However the comment above
clearly highlight an issue arising from running an almost exclusively PHP+JS
shop and under adoption of FOSS development methodologies

That being said:

Using FOSS tools has a higher total cost of ownership. Managers who
authorized a switch from a working system (SVN/Code review) to a new and
immature systems such as Git/Gerrit - should have set aside resources (time
& money) to offset the problems created by  such migrations.

These generally amount to several orders of magnitude of the actual cost of
the migration done by operations. The bulk of the work created by these
changes are offset to the individual developers whose project will be broken
by change of workflow and who might not be active. It passing strange how
few of the extensions are under-maintained, unsupported. 

For example:
* Integration of Gerrit to our system, 
* Customization (adding features like better diffs)
* Acceptance - getting people to change workflow and getting core developers
to actually review code.
* Education - Teaching established and new users to work with the
Git/Gerrit, writing tutorials, training people with them at Hackatons.
Updating project documentations and readmes
* Secondary migration - fixing scripts/apis that depend on the current
setup. E.g. my CI work in December needs to be updated to reflect using
GIT/Gerrit; build scripts of systems with independent modules like search +
mwdumper; updating robots and so on.
* Tertiary migrations - On the developers machines. Replacing IDEs and
Workspaces to reflect the Git/Gerrit workflows.

Thus switching forth between different Gerrit alternative is myopic. It
ignores the friction and cost these moves create for the established
developers community who have created hundreds of extensions and documented
them. I say we just get consensus on the Priority Queue of outstanding
Gerrit issues and start fix them until it rocks.


Oren Bochman
Lead of Search






___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l