Re: Git Survey 2011; now let's not forget the index/cache/stage

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 20 Sep 2010, Felipe Contreras wrote:

> I am *extremely* disappointed with the fact the git survey doesn't
> have a way to determine how many people really use the
> index/cache/stage; I think it's one of the most important features of
> git, and I'm fairly certain most users don't know about it.

Doesn't "interactive commit / per-hunk comitting / partial commit" cover
"git index / cache / stage" response by being what git index is used for 
in explicit way?
 
> IMO the main purpose of the survey is to find out areas of improvement
> in git, and I was hoping this year it would be obvious the stage
> needed some help to make it more visible and accessible.

I don't think that having "git index / cache / stage" as a choice of
answer in multiple-choice '16) Which of the following features do you 
use?' question would tell us that.

If there were "better support for staging / interacting with index"
(perhaps with footnote describing it in more detail below) in the
'17) Which of the following features would you like to see implemented 
in git?' question, but IIRC it wasn't present in your proposal.

> 
> You agreed it would be there, and it's not, so I wonder what's the
> point of asking for feedback if it's going to be forgotten. Next time
> I think you should send the final version for review before
> publishing.

There were two issues conflated that contributed to this error
of mine.

First, I have re-checked *direct email* responses to request for 
feedback on Git User's Survey 2010 questions proposal, but I have 
forgot to re-check responses which were send only to git mailing list 
without Cc (i.e. in my case *newsgroup* responses).  I am very sorry 
for that.

Second, I has a bit unplanned time away from Internet access at the end 
of August, so I had only about a day to do re-check, edit and open the 
survey on 1 September.  I should have edited survey as soon as i got 
improvement suggestion, but the fact that one has to close all channels 
before adding new answer to a multiple-choice question (I think 
Survs.com did it for a good reason) made me postpone it.

> 
> I don't think I would care about the results this year, so can we have
> a wiki with next years's survey? I *really* want to make sure it gets
> there.

Well, nobody prevents you from starting GitSurvey2011 page on git wiki.
You can use older version of GitSurvey2010 as a template:
  https://git.wiki.kernel.org/index.php?title=GitSurvey2010&oldid=8988
(click edit and copy the contents).  Having a year for discussion about 
what questions should there be in user's survey would only improve it.

I can even post on git wiki (probably in sub-pages) the emails I have 
send to git hosting sites to announce the survey.


P.S. I can even add you as a member to 'git' account on Survs.com, so
you would be able to view and even edit survey there, but the Premium 
plan, which we have thanks to generosity of Survs.com administration 
(received after Survs.com got out of beta - first survey on Survs.com 
was run on beta), will downgrade to the Free plan on Sep 22, 2011.

Currenly the survey has more than 5000 responses (in a not whole month),
so any plan outside of Premium is out of question.  We can run 2011 
survey earlier so it wouldn't hit downgrade time, try to move to other 
survey site (http://survey.net.nz got closed, unfortunately), create 
our own survey app e.g. on Google App, ask Survs.com admins for further 
generosity, or pay for Premium account ($119/month) at least for the 
time the survey runs.

-- 
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]