While we're at it, I don't have karma either, can you add all committers?
On Thu, Jun 27, 2013 at 11:53 AM, Vinod Kone <[email protected]> wrote: > Hey Chris, > > I'm unable to login to the wiki anymore (maybe something to do with the > upgrade). I created an account again (username: vinodkone, > email:[email protected]). Would you mind granting me the karma again? > Sorry for the trouble. > > Also, is it possible for non-committers to be given wiki access. I'm > looking into giving edit access to our GSOC intern for example. > > > On Tue, Jun 18, 2013 at 10:45 PM, Mattmann, Chris A (398J) < > [email protected]> wrote: > > > Hey Vinod, > > > > I went ahead and added perms individually for you on the wiki. > > Let me know if that worked. > > > > Cheers, > > Chris > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Chris Mattmann, Ph.D. > > Senior Computer Scientist > > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > > Office: 171-266B, Mailstop: 171-246 > > Email: [email protected] > > WWW: http://sunset.usc.edu/~mattmann/ > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Adjunct Assistant Professor, Computer Science Department > > University of Southern California, Los Angeles, CA 90089 USA > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > > > > > > > > > > -----Original Message----- > > From: <Mattmann>, jpluser <[email protected]> > > Reply-To: "[email protected]" < > [email protected] > > > > > Date: Monday, June 17, 2013 5:37 PM > > To: "[email protected]" <[email protected]> > > Subject: Re: [DISCUSS] Release process on wiki > > > > >Hey Vinod, > > > > > >I can assign individual permission to you I think, but I can't modify > > >the mesos-committers group. > > > > > >I'll raise an issue with infra@ and see if they can give me the ability > > >to modify the mesos-committers group (wiki admin perms). I have space > > >admin perms atm. > > > > > >Cheers, > > >Chris > > > > > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >Chris Mattmann, Ph.D. > > >Senior Computer Scientist > > >NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > > >Office: 171-266B, Mailstop: 171-246 > > >Email: [email protected] > > >WWW: http://sunset.usc.edu/~mattmann/ > > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >Adjunct Assistant Professor, Computer Science Department > > >University of Southern California, Los Angeles, CA 90089 USA > > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > >From: Vinod Kone <[email protected]> > > >Reply-To: "[email protected]" > > ><[email protected]> > > >Date: Sunday, June 16, 2013 9:13 PM > > >To: "[email protected]" <[email protected]> > > >Subject: Re: [DISCUSS] Release process on wiki > > > > > >>Btw Chris, do you have the ability to grant me edit access for the > mesos > > >>wiki page? I would like to use it to capture some stuff (e.g., new > > >>feature > > >>design)? If you don't I can create an INFRA ticket? > > >> > > >> > > >>On Fri, Jun 14, 2013 at 7:19 PM, Mattmann, Chris A (398J) < > > >>[email protected]> wrote: > > >> > > >>> Heya Vinod, > > >>> > > >>> -----Original Message----- > > >>> > > >>> From: Vinod Kone <[email protected]> > > >>> Reply-To: "[email protected]" > > >>><[email protected] > > >>> > > > >>> Date: Friday, June 14, 2013 3:12 PM > > >>> To: "[email protected]" <[email protected] > > > > >>> Subject: Re: [DISCUSS] Release process on wiki > > >>> > > >>> >Thanks Chris for your POV. I think we all agree that Wiki is more > user > > >>> >friendly than git. But my (and likely others) concerns are > > >>> > > > >>> >1) If docs are editable on both wiki and git, then which one is the > > >>> >authoritative source? If one of them goes stale, which one should > the > > >>> >user/contributor refer to? > > >>> > > >>> Great question -- why does one have to be the authoritative source > over > > >>> the other? It's quite possible that they won't have overlapping > > >>>content. > > >>> And if they do, it really only costs us an email to a (potentially > > >>> confused) > > >>> user pointing them at the right source. This requires us to be active > > >>>on > > >>> the dev lists and responsive and looking to help -- Mesos right now > > >>> definitely > > >>> fits that bill. I'm sure you or Ben H or Ben M or Andy or anyone else > > >>> (even me!) :) > > >>> may be able to point peeps in the right direction on that. > > >>> > > >>> > > > >>> >2) How to keep the docs in sync? If some one edits the docs in the > > >>>wiki, > > >>> >how do we get it into our git repo? This involves PMC/Committer to > > >>> >shepherd > > >>> >no? Then why not involve pmc/committer early and circumvent the wiki > > >>>edit? > > >>> > > >>> Who sez they have to be in sync? Like I said they could be > overlapping > > >>> content, > > >>> or not. If they are overlapping then one can grow stale but I would > > >>> estimate the > > >>> cost function for that to be minimal. And it may be driven by our own > > >>> interest > > >>> to fix this or we may have some superstar user that fixes it for us > > >>>that we > > >>> then nominate for PMC and then sign them up for this fantastic task > > >>>(heh). > > >>> > > >>> > > > >>> >3) How easy is it to associate documentation to releases in Wiki? > Its > > >>> >straightforward when we work in the repo. > > >>> > > >>> +1 release docs shipping with releases makes perfect sense to me. No > > >>>reason > > >>> though that there can't be complementary (even overlapping) docs on > the > > >>> wiki. > > >>> No biggie. > > >>> > > >>> > > > >>> >Maybe, one way we could let users use wiki to contribute is, if > there > > >>>is > > >>> >tooling available that can generate a ReviewBoard patch when someone > > >>>edits > > >>> >a wiki, ala github pull request to RB patch? > > >>> > > >>> Haha, yikes that sounds like work for you guys (PMC) that you don't > > >>>need > > >>> to do. > > >>> Let users and contributors edit the wiki to the hearts content and > > >>>improve > > >>> Apache > > >>> Mesos doc. The policies/procedures for what's canonical/etc. in those > > >>>docs > > >>> can be > > >>> less formal and more based on social norms; users' actual comments; > and > > >>> improvements > > >>> that make sense to expend resources working on. > > >>> > > >>> > > > >>> >P.S: Open office's how to contribute to > > >>> >wiki< > > >>> > http://wiki.openoffice.org/wiki/Documentation/Dashboard/Wiki_Editing_ > > >>> >Policy> > > >>> >looks > > >>> >pretty ominous to me :) > > >>> > > >>> Hehe, same to me! /me ducks from the Apache Ooo PMC members sneaking > > >>> around on this list lol > > >>> > > >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >>> Chris Mattmann, Ph.D. > > >>> Senior Computer Scientist > > >>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > > >>> Office: 171-266B, Mailstop: 171-246 > > >>> Email: [email protected] > > >>> WWW: http://sunset.usc.edu/~mattmann/ > > >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >>> Adjunct Assistant Professor, Computer Science Department > > >>> University of Southern California, Los Angeles, CA 90089 USA > > >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >>> > > >>> > > >>> > > >>> > > > >>> > > > >>> >On Fri, Jun 14, 2013 at 2:39 PM, Mattmann, Chris A (398J) < > > >>> >[email protected]> wrote: > > >>> > > > >>> >> Hi Dave, > > >>> >> > > >>> >> -----Original Message----- > > >>> >> > > >>> >> From: Dave Lester <[email protected]> > > >>> >> Reply-To: "[email protected]" > > >>> >><[email protected] > > >>> >> > > > >>> >> Date: Friday, June 14, 2013 11:26 AM > > >>> >> To: "[email protected]" > > >>><[email protected]> > > >>> >> Subject: Re: [DISCUSS] Release process on wiki > > >>> >> > > >>> >> >On Thu, Jun 13, 2013 at 7:29 PM, Mattmann, Chris A (398J) < > > >>> >> >[email protected]> wrote: > > >>> >> > > > >>> >> >> I would just do both. Let contributions and time > > >>> >> >> decide; rather than just picking one. > > >>> >> > > > >>> >> > > > >>> >> >I disagree. In this case I see two distinct concerns related to > > >>> >> >documentation and the wiki: 1) making it clear and simple for how > > >>>to > > >>> >> >contribute to the project documentation, and 2) making it easy to > > >>>use > > >>> >>the > > >>> >> >documentation and get started with Mesos. > > >>> >> > > >>> >> And: > > >>> >> > > >>> >> 3) Enabling contribution to documentation (which is different from > > >>>#1 > > >>> >> [making > > >>> >> it clear] and from #2 [using the documentation]) > > >>> >> > > >>> >> > > > >>> >> >I personally think the latter concern much more pressing for user > > >>> >>growth > > >>> >> >at > > >>> >> >this time, although I do think both are important to consider. Do > > >>> >>others > > >>> >> >think the former is more important? > > >>> >> > > >>> >> I'm of the mindset having been around the foundation since 2005-, > > >>>and a > > >>> >> number > > >>> >> of projects that each (shipping docs with release; and keeping > docs > > >>>in > > >>> >> wiki) has > > >>> >> their benefits and use cases. The latter allows documentation to > > >>>evolve > > >>> >> much more > > >>> >> rapidly and also visually (e.g., through editors like Confluence); > > >>> >>whereas > > >>> >> the > > >>> >> former requires someone with commit/PMC bit to shepherd the > > >>> >>documentation > > >>> >> into > > >>> >> the sources [giving them the potential for them to be quite stale > as > > >>> >>those > > >>> >> sources > > >>> >> become stale]. > > >>> >> > > >>> >> However the above is a straw man.I see advantages to both and have > > >>>lived > > >>> >> them > > >>> >> through in a number of high and low profile open source projects. > > >>> >> > > >>> >> > > > >>> >> > As a developer who is getting starting with Mesos, having > multiple > > >>> >> >sources > > >>> >> >of truth for the project (documentation stored in git, and also > the > > >>> >>wiki) > > >>> >> >could be frustrating. > > >>> >> > > >>> >> Note the key word above *could*. We don't have people constantly > > >>>coming > > >>> >>to > > >>> >> the mailing lists complaining about this delineation. And if they > > >>>did, I > > >>> >> would > > >>> >> suggest to them the same (and it really depends on what their role > > >>>is in > > >>> >> the > > >>> >> project -- are they PMC/committer yet? are they simply a user?, > > >>>etc.) > > >>> >> > > >>> >> Take for example Apache Open Office -- a very formal PMC > > >>>organization > > >>> >> rightly so > > >>> >> due to the diversity of types and kinds of contributions -- and > due > > >>>to > > >>> >>the > > >>> >> fact that their community wants the model that way. Imagine the > > >>> >>rate/types > > >>> >> of > > >>> >> documentation contribution and from all over the world with > > >>> >> internationalization > > >>> >> etc that they receive. Keeping docs in sources would be quite > > >>>difficult > > >>> >>if > > >>> >> updating those docs required the contributors to be PMC or > committer > > >>>- > > >>> >> especially > > >>> >> in the case that they receive non technical documentation and > > >>> >> contributions from > > >>> >> people that will never touch SVN or Git, like ever. But they write > > >>> >> documentation in > > >>> >> e.g., some editor or wiki, and then contribute it separate of the > > >>> >>release > > >>> >> cycle of > > >>> >> the system. > > >>> >> > > >>> >> On the opposite extreme end, in a project with very small sources; > > >>>high > > >>> >> rate of > > >>> >> commit; tons of inclusivity; I can see saying look we want docs > only > > >>>in > > >>> >> sources, > > >>> >> we don't need a wiki being a decent choice. Until the first user > > >>>that > > >>> >> cares nothing > > >>> >> about the sources, but only the binary, and that writes a great > > >>>tutorial > > >>> >> on the > > >>> >> software and wants to share it comes along. Then what's the use > > >>>case? > > >>> >>That > > >>> >> tutorial > > >>> >> has to be shepherded or brought into the sources by a committer or > > >>>PMC > > >>> >> member, creating > > >>> >> more work. When instead, that user could have gone to a wiki, > turned > > >>>the > > >>> >> editor on, > > >>> >> dumped their doc into it, clicked save, and been done. It's in our > > >>> >> advantage to have > > >>> >> the docs here on ASF hardware and the bits here, in whatever form > > >>>they > > >>> >> manifest (wiki; > > >>> >> *.md files in Git, etc.) > > >>> >> > > >>> >> Mesos isn't on either end of these opposites, and is more > in-between > > >>> >>like > > >>> >> most > > >>> >> projects are. For that reason along with numerous others I've > > >>>suggested, > > >>> >> it probably > > >>> >> makes sense to support both. > > >>> >> > > >>> >> Beyond this, it's also not a question of "shutting down" > > >>>documentation > > >>> >>on > > >>> >> the wiki. > > >>> >> That's not something really that should be dictated, nor is it > very > > >>> >> community friendly. > > >>> >> I'm involved with the project, if for nothing else than teaching > the > > >>> >> Apache way, vote'ing > > >>> >> on releases and mentoring. I enjoy the wiki, a lot more than I do > > >>> >>checking > > >>> >> out a source > > >>> >> tree, running a few git commands and then update/pushing it and > > >>>waiting > > >>> >> for it to appear > > >>> >> on some site. For that reason that there is at least 1 person on > the > > >>> >> project that likes > > >>> >> a wiki, I'd ask, VOTE'ing to declare one versus the other defunct > or > > >>>not > > >>> >> isn't very > > >>> >> friendly to me or anyone else that likes the wiki. I'd ask: what > > >>>happens > > >>> >> if everyone > > >>> >> +1s the Git docs, and -1s me? What should I do then? Stop putting > > >>>stuff > > >>> >>on > > >>> >> the wiki? > > >>> >> What if it discourages me from contributing docs? Is that good for > > >>> >>Mesos? > > >>> >> Or the community? > > >>> >> > > >>> >> >There's no search between the docs and wiki, and I'm > > >>> >> >not clear if there is a distinction between where I would go to > > >>>answer > > >>> >> >specific questions. When contributing documentation, I'm also not > > >>>sure > > >>> >> >which source I would contribute to. > > >>> >> > > >>> >> Hypothetical, let's support this with real use cases and data and > > >>> >>address > > >>> >> this issue should it arise when we have dozens of people beating > our > > >>> >>door > > >>> >> down for searching across the wiki and docs -- furthermore, I'd > > >>>actually > > >>> >> suggest that in fact you can search across both, with Google. > Google > > >>> >> indexes > > >>> >> Apache's Confluence deployment; as do they index our Git and SVN > > >>>repos > > >>> >>and > > >>> >> the content inside. So, you can actually search across both. B/c > > >>>Google > > >>> >>is > > >>> >> a > > >>> >> horizontal search engine and not vertical, it's harder, but it can > > >>>be > > >>> >>done. > > >>> >> > > >>> >> > > > >>> >> >I'm in favor of using just one source. If making it easy to use > the > > >>> >> >documentation is the priority then I think rendering markdown > files > > >>>is > > >>> >>a > > >>> >> >fine approach for now. > > >>> >> > > >>> >> My honest suggestion: put your time and effort into improving what > > >>>you'd > > >>> >> like > > >>> >> (the source docs), and let me and anyone else that wants to put > > >>>stuff on > > >>> >> the > > >>> >> wiki do our thing too. Then, beyond that, let's add a link on > both: > > >>>(1) > > >>> >> from > > >>> >> the wiki to git: Apache src docs; and from src docs to the wiki. > > >>>Done. > > >>> >> > > >>> >> Cheers, > > >>> >> Chris > > >>> >> > > >>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >>> >> Chris Mattmann, Ph.D. > > >>> >> Senior Computer Scientist > > >>> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > > >>> >> Office: 171-266B, Mailstop: 171-246 > > >>> >> Email: [email protected] > > >>> >> WWW: http://sunset.usc.edu/~mattmann/ > > >>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >>> >> Adjunct Assistant Professor, Computer Science Department > > >>> >> University of Southern California, Los Angeles, CA 90089 USA > > >>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >>> > > >>> > > > > > > > >
