At the risk of threadjacking about dogfooding.... On Tue, Sep 27, 2016 at 2:45 PM, Legoktm <[email protected]> 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
