Great point: down the road we will use ML search and that doesn't index the content of links to docs.
Thus I concur its reasonable to discuss initial proposals and settling direction on ML, and finally linking to a wiki/gdoc which summarizes the conclusion. That doc can continue to make small churn on the details, but new major shifts in direction should be a ML thread. Sound right? -Michal On Fri, Apr 5, 2013 at 3:08 PM, Michael Brooks <[email protected]>wrote: > > > > My main problem is starting a proposal or draft on a website to begin > > with. The initial discussion, in my mind, should be done on the list in > > email form, so the apache archives have a clear record of how a > discussion > > about a new proposal or feature has evolved. > > > This summaries that main concern. It's not being too lazy to click a link > or communication of revisions. It's that in 5 years from now, the Cordova > project will have lost and gained contributors, but the evolution of each > proposal will still be accessible because it has been captured > and archived by Apache's Infrastructure. > > > > > On Fri, Apr 5, 2013 at 11:59 AM, Filip Maj <[email protected]> wrote: > > > My main problem is starting a proposal or draft on a website to begin > > with. The initial discussion, in my mind, should be done on the list in > > email form, so the apache archives have a clear record of how a > discussion > > about a new proposal or feature has evolved. > > > > So instead of "here's my proposal: link", it would be "here's my > proposal: > > text dump from the link" > > > > In terms of documenting the proposal as it evolves from the list, I don't > > care whether it's in Gdocs or in the wiki. > > > > On 4/5/13 11:56 AM, "Michal Mocny" <[email protected]> wrote: > > > > >-1, but hey, what can you do.. > > > > > >I guess that if we don't like opening links, then we will be consuming > > >wiki > > >doc proposals via the wiki-update emails that go out? Also, since it > > >emails for each patch, perhaps update the wiki with as few commits as > > >possible, including when making comments, and ideally without causing > edit > > >conflicts with others editing. Shish, good luck. > > > > > >-Michal > > > > > >On Fri, Apr 5, 2013 at 2:36 PM, tommy-carlos Williams > > ><[email protected]>wrote: > > > > > >> +1 > > >> > > >> Guiltily admitting to being in the not-opening boat with Fil :/ > > >> > > >> On 06/04/2013, at 4:22, Filip Maj <[email protected]> wrote: > > >> > > >> > +1, it's a bad excuse on my side but the extra step in opening the > > >>link > > >> is > > >> > sometimes enough to discourage me from even looking at proposals :P > > >> > > > >> > On 4/5/13 10:18 AM, "Michael Brooks" <[email protected]> > > wrote: > > >> > > > >> >> Hey guys, > > >> >> > > >> >> I know this has been on the minds of a number of contributors and I > > >>want > > >> >> to > > >> >> bring it up on the list. > > >> >> > > >> >> I think we need to stop using Google Docs for drafting our plans, > > >> >> specifications, and such. > > >> >> > > >> >> For myself, this is a little disappointing because I like Google > Docs > > >> and > > >> >> I > > >> >> think it's easy to comment and amend the document. However, the > data > > >>is > > >> >> not > > >> >> hosted by Apache Infrastructure and the changes are not captured on > > >>the > > >> >> source control, mailing list, issue tracker, or wiki. In other > words, > > >> it's > > >> >> side stepping the regular channels that contributors would monitor. > > >> >> > > >> >> For future documents, we should be using the wiki. The wiki does > > >>support > > >> >> rendering comments [1], so we can achieve the same effect as Google > > >> >> Docs... > > >> >> just in a more awkward way. > > >> >> > > >> >> Thoughts? If someone can make a compelling case to keep using > Google > > >> Docs, > > >> >> I'm all ears. > > >> >> > > >> >> Michael > > >> >> > > >> >> [1] http://wiki.apache.org/cordova/HelpOnComments > > >> > > > >> > > > > >
