Hi, On Mon, Sep 20, 2010 at 4:38 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > 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? Well, that's one part of the stage usage; there's a subset of 'git checkout', and 'git diff --cached' that are totally uncovered. I think somebody might be doing 'git add -i' without understanding where the commit is going. >> 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. Well, if the users actually knew what the stage is, your idea would certainly be better, but I'm not so sure that's the case. A user might select "interactive commit / per-hunk comitting / partial commit" without realizing that's using the "stage", and just skip the question without thinking too much about it. So I think the first step would be to determine if people know what the stage is, and if they use it. >> 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. Ok, but still, I think a final notification one week or so before would help. Either posting the last version, or just point the wiki. >> 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. Ok, I'll do that when I have time :) > 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. Sure, but I only would feel comfortable of updating the site after some agreement has been reached on the wiki or ml. Cheers. -- Felipe Contreras -- 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