Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Rob Lanphier]

At the risk of threadjacking about dogfooding

On Tue, Sep 27, 2016 at 2:45 PM, Legoktm  wrote:
> On 09/27/2016 03:57 AM, Quim Gil wrote:
>> * Phabricator form to submit Wikimedia developer Summit 2017 proposals
>> (urgent because it blocks the opening of the call for participation)
>> https://phabricator.wikimedia.org/T146377
>
> I have proposed the opposite on the ticket[1] - I believe we should be
> using mediawiki.org to organize the summit instead of Phabricator. I
> find it demoralizing that we cannot use our own online collaboration
> software to plan our own summit. We need more dogfooding[2], not less.
>
> [1] https://phabricator.wikimedia.org/T146377#2670042
> [2] https://en.wikipedia.org/wiki/Eating_your_own_dog_food

It's really unfortunate that you consider use of Phabricator to be
demoralizing, though.  I don't want to push something that seems
demoralizing to a great contributor like yourself.  More on this in a
bit

The "Eating your own dog food" article talks a lot about Microsoft's
use of the term, which makes sense because Microsoft was pretty proud
of their dogfooding strategy.  Dogfooding was the right strategy for
Microsoft in the early 1990s, given what they were trying to
accomplish, which world dominance of Microsoft operating systems.  It
worked well for them.  It may be a little naive to hope it will
somehow make our software better at doing the thing it was designed to
do when we try to force it to do something it wasn't designed to do.

The dogfooding article also points out many problems in the
"Criticism" section, where it cites an IEEE magazine editorial on the
subject.  Here's a quote from the cited article[2]:

> Also, dogfooding encourages the Not Invented Here syndrome. If the
> organization's philosophy is that employees must always use its own tools,
> scarce resources might get allocated to building tools that could easily
> be purchased from others, or worse yet, tools might get rejected simply
> because the company doesn't make them.

Sometimes, a non-Wikimedia system may be the best food ... er, tool
for the job.  We shouldn't compromise on WMF's guiding principles[1]
(which we hope are a reflection of movement principles), but we
shouldn't insist on using our own systems when a system developed
and/or maintained by someone else would be the best tool for the job.
Let's shoot for better interoperability with the rest of the free
software world, rather than mindless world dominance of
Wikimedia-controlled software.

So, that's my rebuttal to the suggestion that we need "more
dogfooding"  I think we do need to get better at using our software.
Certainly, MediaWiki is hard to beat at collaborating on prose,
providing great attribution functionality about article changes.  I've
frequently called for ArchCom-RFC authors to move the bulk of the
prose of their RFCs onto mediawiki.org.  However, Phabricator is
really good tool for a couple of things:
1.  Doling out short unique identifiers of tasks, events, etc
2.  Maintaining state metadata about tasks (e.g. bug reports, RFCs, etc)

...plus many other things we use Phabricator for.

So, what about our use of Phab for this makes you glum?  Is there a
way we can convince you that it's not so bad?  I'm open to being
convinced that we should stop using Phab for as much as we are, but
right now, it makes me happy that we have a tool that is rapidly
improving without Wikimedia Foundation needing to invest very much
money in it.  It makes me especially happy that Phab is free software,
and that the time and money we invest in it is making the universe of
free software better.

Rob

[1]: https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles
[2]: https://www.computer.org/csdl/mags/so/2006/03/s3005.html

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

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Legoktm]

Hi,

On 09/27/2016 03:57 AM, Quim Gil wrote:
> * Phabricator form to submit Wikimedia developer Summit 2017 proposals
> (urgent because it blocks the opening of the call for participation)
> https://phabricator.wikimedia.org/T146377

I have proposed the opposite on the ticket[1] - I believe we should be
using mediawiki.org to organize the summit instead of Phabricator. I
find it demoralizing that we cannot use our own online collaboration
software to plan our own summit. We need more dogfooding[2], not less.

[1] https://phabricator.wikimedia.org/T146377#2670042
[2] https://en.wikipedia.org/wiki/Eating_your_own_dog_food

-- Legoktm

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

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Info WorldUniversity]

Rob, Quim and Wikidatans,

Is there a current (curated) summary of all the good suggestions for
WikiDev themes, and structuring of conference, in various email threads
from the past week or two which you could possibly suggest looking at as
key organizers of this? (I shared some Wikimedia
language-ontology-translation related questions along with WUaS development
questions, like in January 2016, I'd like to explore in the
#wikimedia-office Office Hour this morning at 9am PST ).

Thank you.

Bests, Scott






On Tue, Sep 27, 2016 at 3:57 AM, Quim Gil  wrote:

> Thank you Rob! I am looking forward to Wednesday meeting.
>
> On Tue, Sep 27, 2016 at 6:28 AM, Rob Lanphier  wrote:
>
> > I'm hoping we find a way to work with people who can't
> > travel, and noting we're also working to make remote participation
> > more rewarding.  This emphasizes the importance of WikiDev17 being a
> > better event for online attendance this year, and the primacy of
> > online conversations in our community's decision making.
> >
>
> Indeed. Anyone interested in improving remote participation in the Summit,
> please check https://phabricator.wikimedia.org/T146613
>
> Quim is
> > chairing the program committee, and I'm one of the members, but my
> > understanding from Quim is that we're still waiting for some invitees
> > to respond.
> >
>
> Yes, I will send them a reminder. In any case, I think we have critical
> mass: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/About
>
>
> > all of the scheduled topics had Phab IDs associated with them.
> >
>
> I agree that RfCs are useful in some cases but not in all of them. However,
> I would still keep a single way to submit proposals as Phabricator tasks,
> in order to have one place with all the proposals. If the promoters of a
> specific proposal want to have the discussion elsewhere (in an RfC page, a
> plain wiki page...) then they can simply put a disclaimer in the task
> description and move the discussion there.
>
> There are two possible novelties related to proposed and scheduled
> activities that we could try at the Summit:
>
> * Phabricator form to submit Wikimedia developer Summit 2017 proposals
> (urgent because it blocks the opening of the call for participation)
> https://phabricator.wikimedia.org/T146377
> * Consider using Phabricator Calendar events to schedule Wikimedia
> Developer Summit sessions (we have more time for this one)
> https://phabricator.wikimedia.org/T146749
>
> --
> Quim Gil
> Engineering Community Manager @ Wikimedia Foundation
> http://www.mediawiki.org/wiki/User:Qgil
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 

- Scott MacLeod - Founder & President

- http://worlduniversityandschool.org

- 415 480 4577

- PO Box 442, (86 Ridgecrest Road), Canyon, CA 94516

- World University and School - like Wikipedia with best STEM-centric
OpenCourseWare - incorporated as a nonprofit university and school in
California, and is a U.S. 501 (c) (3) tax-exempt educational organization.


World University and School is sending you this because of your interest in
free, online, higher education. If you don't want to receive these, please
reply with 'unsubscribe' in the body of the email, leaving the subject line
intact. Thank you.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] SQLite Mediawiki support

[Jefsey]

At 18:42 26/09/2016, Aran wrote:
Content-Transfer-Encoding: base64I developed a MediaWikiLite system 
many years ago which worked

reasonably well. It was for having a wiki on a memory stick that
included the content and ability to edit it in the field without net
access.


Yes. Also easy back-up and replication. With extenbots around. Then 
the various wikilites being networked.



 It ran on SQLite and use Nanoweb, a web-server written in PHP to
reduce dependencies further.

It's very out of date now, but may be helpful:

https://www.organicdesign.co.nz/MediaWikiLite


Thanks. I had a read and will come back to it as I probably set-up a 
working group.

Best
jfc




On 26/09/16 11:00, Jefsey wrote:
> The personal way I am using wikimedia as an SQLite textbase I can
X\Ú[HÛÜKؘ@ckup from machine to machine and modifiy through
> external bundled applications leads me to consider there is a need for
HÚZÚ[YYXH\Ù\ˆL  HÛÛ\]X›H•ÒRÒS]Hˆ[egrated/maintained
> solution set.
ˆKˆ\ÈÛÛY][™Èike that been investigated in the 
pastˆ‹ˆHÛÝ[™H@nterested by comments on the idea?

ˈ[ÛÈX›Ý]H\proach that can best help users and possibly
> wikimedia dévelopment?
ˆH›ÝH]\ÈH™]ÛܚÙY[™]šYX[Ürofessionnal I am interested in
][KXYÙ[ÜšY[Y[€terwares and would like to investigate
> "wikilite" networking capabilities (both about what networked
> architectures could bring, and aboout capacity based content
> security/protection).
>
> Thank you for your attention.
™@st
> jfc
>
>
>
×À_
> 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

Re: [Wikitech-l] SQLite Mediawiki support

[Jefsey]

At 00:36 27/09/2016, Brian Wolff wrote:
Content-Transfer-Encoding: base64Mediawiki supports sqlite. And you 
can pretty much use with any webserver -

so are you basically asking for an installer? Some sort of xulrunner-esque
thing so the interface doesnt look like a web browser?


I did not know XULetc... So, some parts could be related. Actually 
the need I have is quite opposite to mediawiki but with the same 
tools: not to support a community with common knowledge, but to 
support a single/a small group of users/authors, with sustainable 
knowledge, i.e. texts I can consantly augment and update, so I can 
structure my "mneme" and build upon it, for me, for others. The key 
issue seems to be individual (wikilite) versus community mneme (wikipedia)


I need the wikipedia proven tools and practices under the form of a 
compact and robuts system I can rely upon and run on my different 
machines through my dropbox directory (the way I actually use the 
same wiki on three machines). However, the difficulty are :


1. mediawiki is not documented in that perspective for technically 
agnostic end-users

2. some of the php tools are not complete for SQLite
3. installation of a new wikilite is still complex and long, I would 
like to be able to install 30 different ones in one minute for a 
group of students, with pre-entered pages, forms, docs,mailing lists, etc.
4. a review of extensions into that perspective - introduced as 
perpetual off-the-shelve part of the experience.
5. farming management and updates (I run around 200 wikilites using 
symlinks for the current release, each in its own directory)
6. I would like to develop specialized bots for content management 
and interfacing, etc. that do not necessarily make sense in broad uses.

etc.

What I would like to get is an end-user oriented (extension and bot 
included) documentation anyone can read, understand and use. Yes, an 
installation and maintenance tool, with various types of use 
configurations,  Then a clear documentation of the maintenance and 
extension tools with quality control and support. To become an 
end-user textbase++ system, consultants should be available and 
turn-click deliveries available (home and in the cloud).


Thx for suggestions.
jefsey



--
Brian

On Monday, September 26, 2016, Jefsey  wrote:
> The personal way I am using wikimedia as an SQLite textbase I can easily
copy/backup from machine to machine and modifiy through external bundled
applications leads me to consider there is a need for a wikimedia user 100%
compatible "WIKILite" integrated/maintained solution set.
>
K€ has something like that been investigated in the past?
 2. I would be interested by comments on the idea?
> 3. also about the approach that can best help users and possibly
wikimedia dévelopment‚ˆH›ÝH]\ÈH™]ÛܚÙ@d individual/professionnal I 
am interested in

multi-agent oriented interwares and would like to investigate "wikilite"
networking capabilities (both about what networked architectures could
bring, and aboout capacity based content security/protection).
>
> Thank you for your attention.
™\ݏˆ™˜‚€£âõõõð___
> Wikitech-l mailing list
ÚZÚ]XÚ[\Ýˀwikimedia.org
΋ËÛ\Ý˝ÚZÚ[YYXK›Ü™ËÛXZ[X[‹Û\Ý@nfo/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

Re: [Wikitech-l] Gerrit screen size

[Paladox]

Not really, since gerrit is a google owned project, and google supports most 
browsers, it is unlikely that Internet Explorer will never be unsupported in 
google projects unless no one uses ie or Microsoft drops all support for 
Internet Explorer. 

On Tuesday, 27 September 2016, 9:39, rupert THURNER 
 wrote:
 

 Isn't Gerrit more for developers who as a consequence anyway run multiple 
browsers and therefore do not care so much that it does not support Ie?
On Sep 26, 2016 20:14, "Paladox"  wrote:

There new skin called polygerrit fixes all the issues described here. It is 
moving along greatly but it doesn't support all browsers yet, namely Internet 
Explorer due to polygerrit using es6 and internet explorer does not support 
es6. They are going to something in the q2 of next year work on internet 
explorer support, hopefully it will make it into gerrit 2.14, 2.15, and 
hopefully we will still be using gerrit then and update it and also hopefully 
polygerrit will have added all the missing features.
Polygerrit is very responsive as I tried this on my mobile (iPhone) and it 
worked.



    On Monday, 26 September 2016, 18:39, Rob Lanphier  
wrote:


 On Sun, Sep 25, 2016 at 5:41 AM, Tim Starling 
wrote:

> On 25/09/16 21:09, Bináris wrote:
> > I try to familiarize myself with Gerrit which is not a good example for
> > user-friendly interface.
> > I noticed a letter B in the upper right corner of the screen, and I
> > suspected it could be a portion of my login name. So I looked at it in
> HTML
> > source, and it was. I pushed my mouse on it and I got another half window
> > as attached.
> >
> > So did somebody perhaps wire the size of a 25" monitor into page
> rendering?
> > My computer is a Samsung notebook.
>
> In T38471 I complained that the old version was too wide at 1163px
> (for my dashboard on a random day). Now the new version is 1520px. I'm
> not sure if the Gerrit folks are serious or are trolling us. Perhaps
> it is a tactic to encourage UI code contributions?
>

My suspicion is that the Gerrit folks (in particular, Shawn Pierce) aren't
so much trolling us as saying "stop relying on the UI of Gerrit!  That's
not the point!"  The last time I was paying close attention to this, Gerrit
upstream seems to be particularly focused on building code review features
suitable for:
1.  Incorporation into git upstream
2.  Integrated into development UIs like Eclipse

The strategy seems to be "Gerrit is a reference implementation of a code
review UI for Git".  I haven't paid close enough attention to either Gerrit
upstream or Git upstream to know if the Gerrit core contributors have made
progress in getting code review functionality added to Git core (or if
they've given up, or if I completely misunderstood their strategy).  I'm
guessing that Eclipse has pretty good Gerrit support, but I rarely play
with Eclipse, so that's just a guess based on the Eclipse Foundation's
involvement with Gerrit.

As bd808 noted, Gerrit upstream seems to be working on yet another UI,
which would make sense if their goal is to create a variety of compatible
implementations of advanced Git functionality.

Rob
__ _
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

Re: [Wikitech-l] Public Event Streams (AKA RCStream replacement) question

[Daniel Kinzler]

Hey Gergo, thanks for the heads up!

The big questions here is: how does it scale? Sending events to 100 clients may
work, but does it work for 100 thousand?

And then there's several more important details to sort out: What's the
granularity of subscription - a wiki? A page? Where does filtering by namespace
etc happen? How big is the latency? How does recovery/re-sync work after
disconnect/downtime?

I have not read the entire conversation, so the answers might already be there -
my appologies if they are, just point me there.

Anyway, if anyone has a good solution for sending wiki-events to a large number
of subscribers, yes, please let us (WMDE/Wikidata) know about it!

Am 26.09.2016 um 22:07 schrieb Gergo Tisza:
> On Mon, Sep 26, 2016 at 5:57 AM, Andrew Otto  wrote:
> 
>>  A public resumable stream of Wikimedia events would allow folks
>> outside of WMF networks to build realtime stream processing tooling on top
>> of our data.  Folks with their own Spark or Flink or Storm clusters (in
>> Amazon or labs or wherever) could consume this and perform complex stream
>> processing (e.g. machine learning algorithms (like ORES), windowed trending
>> aggregations, etc.).
>>
> 
> I recall WMDE trying something similar a year ago (via PubSubHubbub) and
> getting vetoed by ops. If they are not aware yet, might be worth contacting
> them and asking if the new streaming service would cover their use cases
> (it was about Wikidata change invalidation on third-party wikis, I think).
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> 


-- 
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

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

Re: [Wikitech-l] Wikimedia Developer Summit 2017 discussion

[Quim Gil]

Thank you Rob! I am looking forward to Wednesday meeting.

On Tue, Sep 27, 2016 at 6:28 AM, Rob Lanphier  wrote:

> I'm hoping we find a way to work with people who can't
> travel, and noting we're also working to make remote participation
> more rewarding.  This emphasizes the importance of WikiDev17 being a
> better event for online attendance this year, and the primacy of
> online conversations in our community's decision making.
>

Indeed. Anyone interested in improving remote participation in the Summit,
please check https://phabricator.wikimedia.org/T146613

Quim is
> chairing the program committee, and I'm one of the members, but my
> understanding from Quim is that we're still waiting for some invitees
> to respond.
>

Yes, I will send them a reminder. In any case, I think we have critical
mass: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/About


> all of the scheduled topics had Phab IDs associated with them.
>

I agree that RfCs are useful in some cases but not in all of them. However,
I would still keep a single way to submit proposals as Phabricator tasks,
in order to have one place with all the proposals. If the promoters of a
specific proposal want to have the discussion elsewhere (in an RfC page, a
plain wiki page...) then they can simply put a disclaimer in the task
description and move the discussion there.

There are two possible novelties related to proposed and scheduled
activities that we could try at the Summit:

* Phabricator form to submit Wikimedia developer Summit 2017 proposals
(urgent because it blocks the opening of the call for participation)
https://phabricator.wikimedia.org/T146377
* Consider using Phabricator Calendar events to schedule Wikimedia
Developer Summit sessions (we have more time for this one)
https://phabricator.wikimedia.org/T146749

-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit screen size

[rupert THURNER]

Isn't Gerrit more for developers who as a consequence anyway run multiple
browsers and therefore do not care so much that it does not support Ie?

On Sep 26, 2016 20:14, "Paladox"  wrote:

> There new skin called polygerrit fixes all the issues described here. It
> is moving along greatly but it doesn't support all browsers yet, namely
> Internet Explorer due to polygerrit using es6 and internet explorer does
> not support es6. They are going to something in the q2 of next year work on
> internet explorer support, hopefully it will make it into gerrit 2.14,
> 2.15, and hopefully we will still be using gerrit then and update it and
> also hopefully polygerrit will have added all the missing features.
> Polygerrit is very responsive as I tried this on my mobile (iPhone) and it
> worked.
>
>
>
> On Monday, 26 September 2016, 18:39, Rob Lanphier 
> wrote:
>
>
>  On Sun, Sep 25, 2016 at 5:41 AM, Tim Starling 
> wrote:
>
> > On 25/09/16 21:09, Bináris wrote:
> > > I try to familiarize myself with Gerrit which is not a good example for
> > > user-friendly interface.
> > > I noticed a letter B in the upper right corner of the screen, and I
> > > suspected it could be a portion of my login name. So I looked at it in
> > HTML
> > > source, and it was. I pushed my mouse on it and I got another half
> window
> > > as attached.
> > >
> > > So did somebody perhaps wire the size of a 25" monitor into page
> > rendering?
> > > My computer is a Samsung notebook.
> >
> > In T38471 I complained that the old version was too wide at 1163px
> > (for my dashboard on a random day). Now the new version is 1520px. I'm
> > not sure if the Gerrit folks are serious or are trolling us. Perhaps
> > it is a tactic to encourage UI code contributions?
> >
>
> My suspicion is that the Gerrit folks (in particular, Shawn Pierce) aren't
> so much trolling us as saying "stop relying on the UI of Gerrit!  That's
> not the point!"  The last time I was paying close attention to this, Gerrit
> upstream seems to be particularly focused on building code review features
> suitable for:
> 1.  Incorporation into git upstream
> 2.  Integrated into development UIs like Eclipse
>
> The strategy seems to be "Gerrit is a reference implementation of a code
> review UI for Git".  I haven't paid close enough attention to either Gerrit
> upstream or Git upstream to know if the Gerrit core contributors have made
> progress in getting code review functionality added to Git core (or if
> they've given up, or if I completely misunderstood their strategy).  I'm
> guessing that Eclipse has pretty good Gerrit support, but I rarely play
> with Eclipse, so that's just a guess based on the Eclipse Foundation's
> involvement with Gerrit.
>
> As bd808 noted, Gerrit upstream seems to be working on yet another UI,
> which would make sense if their goal is to create a variety of compatible
> implementations of advanced Git functionality.
>
> Rob
> ___
> 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