Page MenuHomePhabricator

Check easily who has signed Legalpad documents by their Wikimedia username
Open, LowPublic

Description

In T258#3289, @flimport wrote:

Jalexander wrote on 2014-08-27 21:38:10 (UTC)
Essentially the main piece of data we need to know is what WM accounts have signed the document(s).

In T258#3281, @flimport wrote:

Jalexander wrote on 2014-07-18 21:34:45 (UTC)
by far the best scenario would be able to see this in the list of signatures (at https://legalpad.wikimedia.org/legalpad/signatures/ etc).

How difficult would it be to add a column with the same type of username links we have now in profiles?

  • Event Timeline

    Qgil created this task.Oct 9 2014, 10:55 PM
    Qgil raised the priority of this task from to Medium.
    Qgil updated the task description. (Show Details)
    Qgil added a project: Legalpad.
    Qgil changed Security from none to None.
    Qgil added subscribers: Qgil, Jalexander.
    Qgil added a subscriber: mmodell.

    I did this before. It's an ugly hack and I'd rather not maintain it but it isn't hard to do:

    https://gerrit.wikimedia.org/r/#/c/147723/

    What has to happen is to sit down and figure out how it will be used. I know Jalexander in particular has spent quite a bit of time outlining what they need, which is great, and in some general terms why. The missing link here is how this will be used. An example is, when this was all first presented I think all of the technical folks assumed that those using legalpad would come looking for a specific person they needed to verify had signed something. I think the actual flow is turning out to be more discovery of users in a general sense with signatures, and less of a "I know this person has said they signed but I need to check". These are really different work flows that we can handle with different compromises in the UI.

    @mmodell's patch is really about throwing stuff at the wall and seeing what sticks because no one on our side understands how the product is used. That patch could be a PITA to manage in an ongoing sense. Something we have seen happen is upstream has really tried not to focus their support time on products that are "beta", and they have even renamed all of them as "prototypes" and made this somewhat clear in the channels. If we can find a workflow that does not involve hacking up the UI and doing heavy handed things that will cause us pain every time we have to merge upstream (which will be very often) it will be much more supportable. That could mean a separate phab app, which may be more work up front but leaves us in a good place for weekly or months merges. It may mean a separate web interface outside of the normal phab one that can be used to run queries against the DB without incurring the costs we are looking at now.

    Delivering something we are not going to be able to actively support well, or that is going to constantly require break-fix energy isn't going to allow us to be very good stewards of this use-case in the most basic senses.

    Could you expand on what you don't understand about the use cases and what, in your opinion, the UI compromises could be? To be honest I feel like I've explained it a few times in both the previous task(s) and in past meetings and so I want to ensure that I don't just repeat something that you found confusing or difficult to quantify.

    One thing I can do, at least it doesn't look very difficult at first glance, is to enable 'advanced search' on the wiki username field. That would not involve any hacks or long term maintenance issues, at least in the sense that it would be isolated to an extension instead of patching the phabricator core. It would also nicely solve the problem of finding a specific wiki user and confirming that they signed document X.

    The 'discovery' use case that @chasemp mentioned would be better served by the patch that I pasted above, but as @chasemp said, it would be better if we can find a way to serve that use case without hacking the core. One solution might be to just clone the user search code and make a separate controller+view that does the same thing. Although this would be duplicating the code it would avoid dealing with merge conflicts when upstream changes touch the code we would be modifying..

    In T607#10078, @mmodell wrote:

    One thing I can do, at least it doesn't look very difficult at first glance, is to enable 'advanced search' on the wiki username field. That would not involve any hacks or long term maintenance issues, at least in the sense that it would be isolated to an extension instead of patching the phabricator core. It would also nicely solve the problem of finding a specific wiki user and confirming that they signed document X.

    The 'discovery' use case that @chasemp mentioned would be better served by the patch that I pasted above, but as @chasemp said, it would be better if we can find a way to serve that use case without hacking the core. One solution might be to just clone the user search code and make a separate controller+view that does the same thing. Although this would be duplicating the code it would avoid dealing with merge conflicts when upstream changes touch the code we would be modifying..

    Great, that gives me a bit of a better understanding of the question.

    While some of the on going (future) work would certainly be 'verify if he's signed' in the end what you are calling discovery is, indeed, the most important. At the start we have almost 900 users who will have to sign (because they already have advanced rights) in relatively short order. We need to see as they are coming in so that they can stop being bothered about it and so that we know when there may be issues. Searching for each individual user would become cumbersome and complicated. This is why my expectation has always been seeing it on the list of signatures itself (it is, indeed, the only thing we really 'need' to see on the list of signatures. We need to store their real name and email but I don't need access to it on a regular basis and I could care less about their Phabricator username.

    On the on going basis the discovery mode (or automated emails about new signatures... though we really don't want that for the first couple months) is also likely to be the most common method just because it makes it easiest to see when there has been a chance and allow us to do the required actions so that they can get the rights they were selected for by the community.

    @chasemp @Qgil When @Jalexander says he's explained it a few times in previous tasks and meetings, he's referring to T258 and it's been pretty clear that they want specifically to have the wiki username in the list, just like this task is requesting.

    @chasemp: I'm willing to prototype implementing this as a separate phabricator application so that we don't have to merge upstream changes to patched code. Would that be an agreeable solution? It would still likely require a small amount of patching but hopefully no more than a single line of code somewhere.

    @Jalexander, really I think you have explained yourself well, but their has been a meager amount of time on our side to address it and translate into the best possible technical terms. I'm genuinely sorry that has sucked. I think the last few comments here have been good. In my mind, saying the solution is a certain identifier in the list is a skip-to-the-end conclusion, but in restating the problem as "we need to know who signed a certain legalpad" I hope it can be handled in more flexible and still amendable ways. Really my fear is delivering something we aren't prepared to sustain.

    @mmodell, Could we do something as simple as a url that is just a list of signee's by wiki name as an extension? Not even bothering with UI fanciness. I'm not trying to be ignorant but for me the need isn't wiki names in the list, it's a list of wiki names with signatures. Which we may better serve in another context.

    On the separate app, maybe take a look at how the burndown chat was built?

    https://phabricator.wikimedia.org/T153
    https://github.com/bluehawk/phabricator-sprint

    That's some pretty advanced stuff all done in a way that is really thoughtful.

    I'm really not trying to be the grinch on this.

    In T607#10082, @chasemp wrote:

    @Jalexander, really I think you have explained yourself well, but their has been a meager amount of time on our side to address it and translate into the best possible technical terms. I'm genuinely sorry that has sucked. I think the last few comments here have been good. In my mind, saying the solution is a certain identifier in the list is a skip-to-the-end conclusion, but in restating the problem as "we need to know who signed a certain legalpad" I hope it can be handled in more flexible and still amendable ways. Really my fear is delivering something we aren't prepared to sustain.

    I understand, to be honest my frustration is more from being under the impression things were happening (after I felt like I had narrowed down to MVP from the rest of the things I thought very important) and them not being. At least some of that is, clearly, me not realizing when the conversation went in another direction and, possibly, the tool itself not really being ready for prime time at the scale we were hoping for (especially with the language issues it and phabricator have) especially some frustration most of my other preferences for the tool dying a death somewhere along the road here or upstream (some understandably, some less so in my mind, but it doesn't really matter why in the end). I clearly made too many assumptions about what was being done. If I had understood the realities earlier on I likely would have created a custom tool or just used email but that's water under the bridge for now.

    @mmodell, Could we do something as simple as a url that is just a list of signee's by wiki name as an extension? Not even bothering with UI fanciness. I'm not trying to be ignorant but for me the need isn't wiki names in the list, it's a list of wiki names with signatures. Which we may better serve in another context.

    On our side this would likely work for the initial use case ('discovery') but while the real name/email are not generally required we do need to get to them when necessary. For that we would need to have some way to at least cross reference the two lists and get the other information. That could take multiple forms of course (The search function you talked about earlier, having one of the 'normal' fields in the list as well etc).

    Qgil added a comment.Oct 10 2014, 6:21 AM

    Thank you all for your thoughts and the illustrative patch. I spoke with @Jalexander a few hours ago, and we exchanged impressions about our respective top priorities. The further comments here are very helpful.

    A summary that hopefully all we can agree on:

    • The Legalpad project is objectively urgent: there is an ongoing community process that needs it, and a board decision to fix this problem. However, due to several circumstances its push has been delayed, and now it is the Phabricator team who requests to wait a bit. We are in the middle of a Bugzilla and a RT migration that require all our focus and more, this is a declared WMF Engineering top priority, and the only sane approach is to put this task aside until we have completed Bugzilla-Migration. We are still hoping to finish by the end of this month, although we haven't committed to a specific date yet.
    • Today we can say that it is technically possible to provide the list with the details needed (say, for each entry Wikimedia username - Real name - Phabricator username - email). We just don't have the time right now to discuss and agree its details, but it looks like it shouldn't be rocket science. Patching upstream's Legalpad would be a short term solution creating a short term problem of maintenance. Since the use case is so unique for Wikimedia, it is unlikely that upstream will be interested in merging such patch, that we would need to maintain locally forever. Therefore, the best approach is an extension.
    • We can also talk about other features like inclusion in advanced search or triggering email notifications when a new users signs a legalpad (a feature that I could not find today via Herald or email preferences) but, again, not before the Bugzilla migration has been completed.

    Nobody wanted to arrive to this date without a Legalpad in full use, but this is where we got somehow. The Phabricator team requests the LCA team to wait just a few more weeks.

    Aye, I think I agree with all of that :) I understand the Bugzilla pressure and have explained it to the rest. We play the cards we're dealt.

    Although advanced search wasn't the most-desired feature, it was a low hanging fruit (it only took a few minutes to implement and test) and this feature might also benefit other users of phabricator so I've gone ahead and created a patch. This is entirely self-contained in the extension, no need to patch core code.

    Here's the code if anyone is interested in reviewing it:

    https://gerrit.wikimedia.org/r/#/c/165985/

    Here's what the mediawiki user field looks like in advanced search on my local test phabricator:

    revi added a subscriber: revi.Oct 10 2014, 8:27 PM
    Qgil lowered the priority of this task from Medium to Low.Oct 24 2014, 11:22 PM
    Qgil added a subscriber: LuisV_WMF.
    In T607#14817, @Qgil wrote:

    Aye, just to clarify for later though: The list is probably still a blocker for us to roll out though (the 1000+ people coming in at the start are just too much for us to search individually for their usernames, I need the list).

    Qgil added a comment.Jan 5 2015, 3:54 PM

    Even if 1000+ people are coming, are you going to search for all of them?

    I'm having a hard time finding users that have declared a Wikimedia SUL username different than their Phabricator username or "also known as", so I wonder how big of a problem this would be in reality.

    I also realized that even if I understand the purpose of the Trusted User Tool, I don't know you plan to use it, which doesn't help when trying to find good solutions. This is why I just created T85808: Document the Phabricator Legalpad (Trusted User Tool) workflows.

    At some point basically every one of them will need to be searched for. Yes.

    I will admit, I feel like I've repeated answers to your work flow questions multiple times now :-/ but obviously not in a way that was helpful for you and for that I apologize. I will try to come up with a better explanation to respond to the new task this afternoon.

    Qgil added a comment.Jan 5 2015, 7:00 PM

    If you have already replied to my questions you don't need to reply them again here. I will read the related tasks trying to find the answers.

    I might have bad memory, too many different projects in my head, or both, but the problem the Trusted User Tool project has is that there is not a single wiki page where it is documented (that I'm aware of).

    I will search for answers and I will documented them in a new wiki page if needed. URLs welcome, no need to explain anything again. :)